Issues found when trying to get OIIO working as a static library on Windows

[DominikGrabiec]

I wanted a public place to write down and discuss the list of issues that I've found while trying to get OIIO building as a static library on Windows and linking it into another executable / dynamic library. I've got fixes for some of these issues but I'm not sure if any single change is the right way to go about it given the history of the project and other platforms and configurations it's used in.

Some advice, guidance, and hints would be appreciated.

I've used the guide that @aras-p has made but I've installed the dependencies with vcpkg to the global location, and reduced the initial CMake command to: cmake -DVCPKG_TARGET_TRIPLET=x64-windows-static-md -DCMAKE_TOOLCHAIN_FILE=E:\vcpkg\scripts\buildsystems\vcpkg.cmake -DBUILD_SHARED_LIBS=OFF -DLINKSTATIC=ON -DVERBOSE=ON -DBUILD_DOCS=OFF -DINSTALL_DOCS=OFF -DBUILD_TESTING=OFF -DOIIO_BUILD_TOOLS=OFF -DOIIO_BUILD_TESTS=OFF -DUSE_PYTHON=OFF -DUSE_QT=OFF -DBoost_USE_STATIC_LIBS=ON .. Which I end up running in the build directory.

This creates for me a Visual Studio solution for which I can build the static OpenImageIO libraries and install them to the dist directory, then point my test exexutable project at it by using -DOpenImageIO_DIR=<OIIO_ROOT>\dist\lib\cmake\OpenImageIO. The test executable just prints out the supported extensions for image loading in OIIO.

These are the issues I've encountered while generating the VS solution and building both the OpenImageIO libraries and the text executables.

• Building the tests OIIO_BUILD_TESTS=ON with the x64-windows-static triplet is broken due to a VC runtime mismatch between the OIIO static library (uses static runtime) and the test executables (uses dynamic runtime). The CMake fix for this would be to put in some generator expressions to change the runtime type, but much easier fixes are to either use the x64-windows-static-md community triplet for vcpkg, or to turn building tests off instead with OIIO_BUILD_TESTS=OFF.
• Building the static library on Windows requires adding find_package(OpenEXR) into the project before find_package(OpenImageIO) otherwise CMake exits with errors. I have a change (DominikGrabiec@a4382d4) which fixes this for me but I'm not sure if it's good as I don't know OpenEXR and how it's used at all.
• Specifying USE_STD_FILESYSTEM on Windows is broken with MSVC because it requires at least C++17 where as OIIO specifies a minimum of C++14. To make this option work we would need to require C++17 if USE_STD_FILESYSTEM is switched on, and I don't know how that will play out with other dependencies and projects.
• When USE_QT=OFF is used there is a warning that the Qt5 library was not found, This is not a fatal error but just looks odd and can be worked around by also specifying USE_QT5=OFF to prevent the call to checked_find_package(Qt5) from emitting the warning. I've got a fix for that in DominikGrabiec@f1603fd
• The ALWAYS_PREFER_CONFIG option in checked_find_package is broken for a number of reasons but one of them is that when using the FindOpenEXR module it defines OPENEXR_VERSION but when using the config version it only has OpenEXR_VERSION and therefore it ends up using IMath version 2. This fix can be as simple as using OpenEXR_VERSION when deciding which version of IMath to use but I'm not sure if the old style OPENEXR_VERSION is used anywhere else.
• There are several image io library dependencies which don't work correctly for a number of reasons in this vcpkg setup. I think these are complex issues and arise from the custom CMake find modules (0aa4d1e). I have banged my head against these issues but only managed to fix one.
  • The libheif library has a dependency on libde265 which it does seem to set up correctly for transitive linking but OIIO doesn't use it correctly. I tried to fix it by adding a if(LINKSTATIC) section to the FindLibheif.cmake module and do different forms of find_package there for libde265 but I couldn't get it to work. The actual fix to make it work came from the vcpkg patches (https://github.com/microsoft/vcpkg/tree/master/ports/openimageio) and I've made a more targetted change in DominikGrabiec@cd6e13d
  • The GIF (presumably from giflib), webp, and bz2 dependencies end up generating full absolute paths in the OpenImageIOTargets.cmake file that gets generated on install. This may be minor but it does prevent the library from being relocatable ala [BUG] Generated CMake config files contain absolute paths #2559
  • The GIF and webp dependencies end up only finding the debug version of the library so that gets linked into all configurations. I think this was also happening with libheif before the change that I made to make it link. My guess is that this is because the CMake find_XXX call ends up searching the vcpkg debug install directory first and just uses that. While the bz2 library also includes full paths for its libraries it does have them split up into optimised and debug versions.
• The boost thread and filesystem libraries don't end up being linked as a dependency when linking OIIO into another executable. I traced this down to $<TARGET_NAME_IF_EXISTS:Boost::****> evaluating to empty for some reason. My simple fix is to go back to linking libOpenImageIO and libutil with ${Boost_LIBRARIES} as it used to be but that does generate absolute paths in OpenImageIOTargets.cmake (See DominikGrabiec@ef3483f)
• Of course there's also my other feature request [FEATURE REQUEST] Make fmt library a true dependency #3595 which I'll try to have a decent fix for soon.