OpenColorIO skips find_package for some 3rd party dependencies when "PackageName_ROOT" is defined

[Willem871]

OpenColorIO has some 3rd party dependencies for which custom "FindPackageName.cmake" files have been written. Examples: yaml-cpp, Imath, minizip-ng,... These all check if the "PackageName_ROOT" variable is defined and if not they call find_package(PackageName). For example for yaml-cpp:

    # Search for yaml-cpp-config.cmake
    if(NOT DEFINED yaml-cpp_ROOT)
        find_package(yaml-cpp ${yaml-cpp_FIND_VERSION} CONFIG ${quiet})
    endif()

The CMake documentation of find_package states however that the location referred to by the variable "PackageName_ROOT" is searched first to find the package. In our build setup we do set this variable so that find_package commands will find the appropriate version (i.e., the one we build from source). Because of "if(NOT DEFINED...)" the find_package call is skipped in this case, which is unexpected behavior for us.

What is the reasoning behind this implementation? At first sight it doesn't seem to comply with the CMake docs.

[remia]

I bumped into related issues where our PkgConfig fallback path to identify the requested version was probably less reliable than the find_package(CONFIG). I don't know / remember why we do this, maybe it was at a time where we supported CMake < 3.12 (seems like the first version supporting PackageName_ROOT in that case). Does this prevent you to get the requested version when building?

[Willem871]

Indeed, we build all 3rd party dependencies from source and we want all our code to use those versions. We enforce this by using CMake config files and by setting the PackageName_ROOT to the library location in our build output folder. The find_package(CONFIG) is then skipped, resulting in some cases in a wrongly found (locally installed) version.