OPENEXR_DLL issues

[meshula]

A very common error users encounter with OpenEXR on Windows is that they have not correctly set the OPENEXR_DLL preprocessor directive to match the OpenEXR build they are linking against. A solution, for CMake users on Windows at least, is that IlmBaseConfig.cmake and OpenEXRConfig.cmake could set the macro appropriately.

We also have generated IlmBaseConfig.h and OpenEXRConfig.h files that would be appropriate places, in a shared build, to add a chunk defining OPENEXR_DLL if it has not been set in the environment already.

See AcademySoftwareFoundation/OpenColorIO#894 for a recent example of the problem.

Historically we wanted one set of headers that would work with static and dynamic libraries living side by side in the build environment, in order to be able to have a lib directory that could be treated as a broad "SDK". A CMake driven build environment does not really work with that notion in mind, and so having a generated macro in the generated headers would better match current practice.

[hodoulp]

You could have a look to the OCIO export defines as an example. The goal is that external users of the library do not have to care about the linkage type.

Below is the OpenColorIO CMake change to correctly handle it:

if(NOT BUILD_SHARED_LIBS)
	target_compile_definitions(OpenColorIO
		PRIVATE
			OpenColorIO_SKIP_IMPORTS
	)
else()
	# Only exports selected symbols.
	target_compile_definitions(OpenColorIO
		PRIVATE
			OpenColorIO_EXPORTS
	)
endif()

[cary-ilm]

Discussed in the TSC, decided there was nothing to do here.