Fix OIIO build against OpenJPH for 2025

[jfpanisset]

src/jpeg2000.imageio/CMakeLists.txt assumes the includes for openjph are in the same location as openjpeg which is not the case when building in Conan.

This doesn't show up in 2026 since openexr 3.4.x declares a dependency on openjph and since OIIO has a dependency on openexr, it gets the include path that way.

[lgritz]

I don't understand what's going on here or why this is necessary. OIIO does not assume that the include files for OpenJPH are in the same location as openjpeg. For OIIO, they are two completely separate 'find' endeavours and end up with two sets of variables and/or targets. For OpenJPH, we rely on that package's exported config files and the openjph target they set up. We don't need anything from openjph to end up the in cmake variables you use.

The line

                       $<TARGET_NAME_IF_EXISTS:openjph>

ought to completely take care of adding openjph support. There is no need to append to those other variables, unless for some reason conan is doing something odd like modifying the openjph exported cmake config in such as way as to not use the expected name for the target?

[jfpanisset]

I realize this hack is unlikely to be the right thing to do but it does get OIIO to build inside Conan.

3.1.7.0 reworks the closely related OpenJPG CMake integration so I am planning to revisit this at that time, hopefully get rid of some of the smellier CMake hacks I've had to do, and possibly upstream what makes sense.

My understanding is that when building in the context of Conan, CMake (mostly?) ignores the CMake code from a dependency and instead relies on its own, auto generated CMake code. So it is entirely possible that the issue is caused by an incorrect / incomplete Conan package definition for OpenJPH.