Applies OPENEXR_DLL only to shared libraries and no longer to static libraries

[OgreTransporter]

All projects of the static libraries are created with the switch -DOPENEXR_DLL However, this switch is only intended for the shared libraries and therefore generates build errors under Windows. Example:

2>D:\test4\src\IlmBase\Imath\ImathVec.cpp(138): error C2491: "Imath_2_5::Vec2<short>::length": Definition von Funktion für dllimport nicht zulässig

See #739

[meshula]

This looks good to me, and it catches the cases I can think of. Thanks for the submission! Due to the complexity of the cmake system we've got, I'd like to request a second set of eyes on the diff please.

[OgreTransporter]

This looks good to me, and it catches the cases I can think of. Thanks for the submission! Due to the complexity of the cmake system we've got, I'd like to request a second set of eyes on the diff please.

I consider this complexity unnecessary. Why not use the standard procedure with BUILD_SHARED_LIBS? Using OPENEXR_BUILD_BOTH_STATIC_SHARED and ILMBASE_BUILD_BOTH_STATIC_SHARED is much too complicated and - as you can see - brings a lot of problems with it. It would be better to either always build static and shared libraries or use BUILD_SHARED_LIBS to build static or shared libraries. It's no problem to run CMake twice if needed, once with BUILD_SHARED_LIBS=ON and once with BUILD_SHARED_LIBS=OFF.

[meshula]

Thanks for the observations @OgreTransporter. The complexity resulted from secondary build steps that generated various look up tables for the build. For many years we considered that it was important to be have those generation steps be part of the build, but they greatly increased build times, and resulted in quite a lot of back forth with developers on many platforms to get the generation steps working properly under a large variety of build conditions. The details are in the project history if you are interested.

The important note is that very recently, as of version 2.5.x, we have checked in the autogenerated header files and no longer build them regularly, as they have not been modified in years, and we don't presently foresee changes.

Now that the source of the complexity has been eliminated, we are starting to pare down and streamline the system, which is greatly helped by welcome community contributions such as yours.

[xlietz]

Please note that this change is breaking one of the MacOS builds. This should be investigated further and resolved before approving.

[xlietz]

Ignore my previous comment. I noticed there was no error log on the failed job. So I re-ran the workflow for this PR and now there are no errors. Note our Windows CI is not functional yet, so it is not actually checking this PR. Would be good for Kimball to review it, if possible.