[FEATURE REQUEST] Make finding ptex more flexible

[sambler]

Is your feature request related to a problem? Please describe. The available options for finding ptex can be too rigid for some setups. The issue stems from PTEX_LOCATION being used for both headers and libraries, with additions also being added to any path being passed in.

If PTEX_INCLUDE_DIR is passed to cmake, it gets overridden by find_path(), same with passing PTEX_LIBRARY.

Describe the solution you'd like I would suggest a similar approach to that used in FindFFmpeg, checking for PTEX_INCLUDE_DIR and PTEX_LIBRARY and only searching if these are not set.

[zomgrolf]

I would also like to see some improvements in this area. We've been looking at building OIIO dependencies on Windows using vcpkg, and have run into some issues with Ptex. We build Ptex as a static library and the file layout used by vcpkg is causing some trouble. Vcpkg puts the debug library in a debug subdirectory of the lib directory and FindPtex tends to find it first, even for release builds. Mixing debug and release libraries on Windows is typically not a great idea, so we'd really like to avoid that, especially that the mix-up usually happens quietly and it's only at link time (if we're lucky) that we discover that something is wrong.

Fortunately, the Ptex port in vcpkg comes with CMake *.config files that define exported targets and point to the right binaries, so it's just a matter of telling CMake to run find_package in config mode (fortunately, this is fairly easy to accomplish in newer versions of CMake by setting CMAKE_FIND_PACKAGE_PREFER_CONFIG to true). That almost gives us what we want, except for one thing: the variables that are set by the config file do not match the ones that are set by FindPtex: for starters, the config file sets the Ptex_FOUND variable, as opposed to PTEX_FOUND which is set by the FindPtex module (and tested by other parts of the build system). Which means, that in the end, we still have to manually patch OIIO build scripts to make this work (or try another way to force FindPtex to behave).

The templates for the config files are included in the Ptex project repo, so I'm guessing that's the 'official' preferred way of consuming Ptex libraries. It would be really nice, if the build script for the Ptex plugin could handle that scenario, as it would really help with streamlining the process of building OIIO on Windows, when using vcpkg to manage its dependencies...

[zomgrolf]

If I'm right, it should suffice to change the CMakeLists.txt in ptex.imageio to something like this:

if (PTEX_FOUND)
    add_oiio_plugin (...)
elseif (Ptex_FOUND)
    add_oiio_plugin (ptexinput.cpp LINK_LIBRARIES Ptex::Ptex DEFINITIONS "-DUSE_PTEX")
endif ()

[etheory]

We've been looking at building OIIO dependencies on Windows using vcpkg.

My advice would be to steer WELL clear of vcpkg for windows. It is, without question, the worst package management software I've ever used on any platform ever, and that's saying something.

Every single update EVER is broken in some new and esoteric way, OIIO almost never correctly compiles using it (the last update randomly stopped adding include and lib paths automatically to cmake scripts....), and it has absolutely no concept of version management at all. It just always builds the latest version, which is incredibly perplexing.

I've poured so many hours into trying to get vcpkg to work, and it's just not worth it.

my2c YMMV etc.

[zomgrolf]

Thanks for the warning, we have been keeping an eye on vcpkg for a while now, but nothing is set in stone yet. However:

1. We don't use vcpkg to build OIIO. Only some of its dependencies (we build Boost separately, for example).
2. Vcpkg has now experimental support for versioning
3. The suggested change should make it possible for OIIO to consume Ptex regardless of whether vcpkg is being used or not, on any platform, as long as Ptex has been installed with the config file and CMake can be pointed to it. OK, this is primarily problem on Windows, but still...
4. Early experiments with using vcpkg to manage the dependencies of OIIO have been rather encouraging. A few relatively minor tweaks/patches aside, it's a fairly smooth process.