Itk: Unbundling openjpeg fails with strict version check.

[TheChymera]

Description

I would like to use the system openjpeg, but ITK seems to want a very specific version which is both too new (slot-wise) and too old (version-wise) to be available on Gentoo Linux.
I could introduce it as a down-grade, but that would be a total disapointment.

Steps to Reproduce

cmake -C /var/tmp/portage/sci-libs/itk-5.0_rc1/work/itk-5.0_rc1_build/gentoo_common_config.cmake -G Unix Makefiles -DCMAKE_INSTALL_PREFIX=/usr -DBUILD_SHARED_LIBS=ON -DITK_USE_SYSTEM_DCMTK=ON -DGDCM_USE_SYSTEM_OPENJPEG=ON -DITK_USE_SYSTEM_DOUBLECONVERSION=ON -DITK_USE_SYSTEM_HDF5=ON -DITK_USE_SYSTEM_JPEG=ON -DITK_USE_SYSTEM_PNG=ON -DITK_USE_SYSTEM_SWIG=ON -DITK_USE_SYSTEM_TIFF=ON -DITK_USE_SYSTEM_ZLIB=ON -DITK_BUILD_DEFAULT_MODULES=ON -DITK_COMPUTER_MEMORY_SIZE=1 -DWRAP_ITK_JAVA=OFF -DWRAP_ITK_TCL=OFF -Ddouble-conversion_INCLUDE_DIRS=/usr/include/double-conversion -DBUILD_TESTING=no -DBUILD_EXAMPLES=no -DITK_USE_REVIEW=no -DITK_INSTALL_LIBRARY_DIR=lib64 -DITK_WRAP_PYTHON=OFF -DCMAKE_BUILD_TYPE=Gentoo -DCMAKE_TOOLCHAIN_FILE=/var/tmp/portage/sci-libs/itk-5.0_rc1/work/itk-5.0_rc1_build/gentoo_toolchain.cmake  /var/tmp/portage/sci-libs/itk-5.0_rc1/work/ITK-5.0rc01

gives me this build.log.

Additional Information

I assume this is the bit of your code which is causing trouble:

find_package(OpenJPEG 2.0.0 REQUIRED).

As you can see in my log, I can only pick 1.5.2 or 2.3.0 . Is ITK guaranteed to fail with these versions, if so with what version would it fail less badly? Lastly, how should I best relax the version check? I understand this may cause unpredicatable behaviour, but since we do dependency management for the entire package set on a system, we prefer to only block versions which are known to fail, and deal with failures if and when they happen. For you this would also mean that in the future you could be notified of package compatibility with versions you have not found the time to test locally :)

[thewtex]

@TheChymera thanks for the report.

2.3.0 should be more compatible than 1.5.2.

Could you please try changing

find_package(OpenJPEG 2.0.0 REQUIRED)

to

find_package(OpenJPEG 2 REQUIRED)

and if it works, please consider submitting a patch.

CC: @malaterre

[malaterre]

@TheChymera let me know how it works thanks

[TheChymera]

@thewtex @malaterre The suggested check did not work, but the following did, I think.

find_package(OpenJPEG 2.* REQUIRED)

What I get now is this build.log.

Looks like a different problem, right? Time for another issue?

[dzenanz]

It is the same issue. From the build log:

CMake Error at Modules/ThirdParty/GDCM/src/gdcm/CMakeLists.txt:378 (find_package):
  find_package called with invalid argument "2.*"

[TheChymera]

Ah, ok :( well, it's not the same issue, though, instead of not being able to match the version, I now have invalid syntax.

The CMake reference suggests

find_package(OpenJPEG 2 REQUIRED)

Should indeed work, but as you can see here, it does not.

[dzenanz]

Having GDCM use OpenJPEG 2.3.0 seems like an easiest solution. Is there any reason no to do so @malaterre?

[TheChymera]

@dzenanz I don't think that's really the solution here. As soon as a distribution version bumps openjpeg, the problem would start all over again. Not least of all, not all distributions might be providing the exact same sub-version (:D) of openjpeg. Ideally we would figure out how to relax the constraint to the major version. Any ideas why CMake doesn't work as described in the reference?

[TheChymera]

Well, in case you don't have any other ideas, for Gentoo specifically, we will be patching the code to read:

find_package(OpenJPEG REQUIRED)

That works for CMake and we have moved the dependency requirement to the appropriate specification for dependency resolution. Thanks for your assistance.

[issakomi]

@dzenanz

Having GDCM use OpenJPEG 2.3.0 seems like an easiest solution. Is there any reason no to do so

GDCM was updated to openjpen 2.3.0. Currently there is one min PR to fix issue with wrong version in cmake file. Seems to work well, for decompression. BTW, there is new cmake option for using threads

FYI, @malaterre
Thanks.