Standalone build of openexr on windows - (with already installed ilmbase)

[SylvainCorlay]

Howdy. I am working on the conda packaging of openexr and ilmbase.

There are two separate packages for ilmbase and openexr.

ilmbase

We download the release tarball from the GitHub releases and

Unix:

./configure --prefix=${PREFIX} \
            --host="${HOST}" \
            --build="${BUILD}" \
            --enable-cxxstd=11

make -j ${CPU_COUNT}
make install

Windows:

mkdir build
cd build

cmake -DCMAKE_INSTALL_PREFIX=%LIBRARY_PREFIX% ^
      -DCMAKE_FIND_ROOT_PATH="%LIBRARY_PREFIX%" ^
      -DBUILD_ILMBASE_STATIC=ON ^
      -DOPENEXR_BUILD_SHARED=ON ^
      -DCMAKE_BUILD_TYPE=Release ^
      -G "NMake Makefiles" ..

nmake
nmake install

We do build the static libraries on windows because they appear to be required by openexr.

openexr

For linux, we download the release tarball from the github releases, and we do

#!/bin/bash
./configure --prefix=${PREFIX} \
            --host="${HOST}" \
            --build="${BUILD}" \
            --enable-cxxstd=11
 make -j ${CPU_COUNT}
make install

and it works beautifully.

On Windows, the release tarball does not appear to have all the necessary assets for a cmake build. Hence, we build from the tarball corresponding to the github tag. Then:

This works: but it vendors ilmbase instead of linking with the other package.

mkdir build
cd build

 cmake -G "NMake Makefiles" ^
      -DCMAKE_INSTALL_PREFIX:PATH=%LIBRARY_PREFIX% ^
      -DCMAKE_BUILD_TYPE:STRING=Release ^
      -DOPENEXR_NAMESPACE_VERSIONING:BOOL=OFF ^
      -DOPENEXR_BUILD_SHARED:BOOL=ON ^
      -DOPENEXR_BUILD_PYTHON_LIBS:BOOL=OFF ^
      ..
if errorlevel 1 exit 1
 nmake
if errorlevel 1 exit 1
 nmake install
if errorlevel 1 exit 1

This and other variations of it appear to fail.

mkdir build
cd build

 cmake -G "NMake Makefiles" ^
      -DCMAKE_INSTALL_PREFIX:PATH=%LIBRARY_PREFIX% ^
      -DCMAKE_BUILD_TYPE:STRING=Release ^
      -DOPENEXR_NAMESPACE_VERSIONING:BOOL=OFF ^
      -DOPENEXR_BUILD_SHARED:BOOL=ON ^
      -DOPENEXR_BUILD_ILMBASE:BOOL=OFF ^
      -DILMBASE_INCLUDE_DIR:PATH=%_LIBRARY_PREFIX%/include ^
      -DOPENEXR_BUILD_PYTHON_LIBS:BOOL=OFF ^
      ..
if errorlevel 1 exit 1
 nmake
if errorlevel 1 exit 1
 nmake install
if errorlevel 1 exit 1

There seems to be some issues with the cmake build that appears to assume that ilmbase is beeing built with openexr.

The generated makefile include things such as: IlmBase::IlmThread_static-NOTFOUND while the IlmBase::{library}_static targets were all properly generated - so there seems to be some issues.

If you know a solution to not build ilmbase and use the installed package, we would love to know! This would be very useful for people who use the conda package manager.

[SylvainCorlay]

OK, it turns out that the entire cmake is very brittle and buggy.

One first issue related to this is a problem of visibility of imported libraries in FindIlmBase.cmake (missing GLOBAL), and the fact that the imported library is static:

1. IlmBase::${ILMBASE_LIB}_static

add_library(IlmBase::${ILMBASE_LIB}_static SHARED IMPORTED)

should be

add_library(IlmBase::${ILMBASE_LIB}_static STATIC IMPORTED GLOBAL)

2. Similarly

add_library(IlmBase::${ILMBASE_LIB} SHARED IMPORTED)

should be

add_library(IlmBase::${ILMBASE_LIB} SHARED IMPORTED GLOBAL)

The second issue is that the IlmImf library is linking with both the static and the dynamic libraries for ilmbase on windows!

[kdt3rd]

cmake has been fundamentally re-written to be using a "modern cmake" style of cmake file using config files, etc. please retest with current master, and or the pending release, and let us know if it still doesn't work (well, we know that finding zlib and boost::python if you want those bindings usually involves a bit of fiddling, but hopefully it works better).

[SylvainCorlay]

cmake has been fundamentally re-written to be using a "modern cmake" style of cmake file using config files, etc. please retest with current master, and or the pending release, and let us know if it still doesn't work (well, we know that finding zlib and boost::python if you want those bindings usually involves a bit of fiddling, but hopefully it works better).

Great news! Thanks for the update.