[question] How to use conan with older cmake 3.19.3?

[garyo]

What is your question?

I have an open source project, OpenFX, and I'm working on building it with conan and cmake. I'm trying to get it building on the VFX Reference Platform which is CentOS 7 and uses cmake 3.19.3. (There's a docker image at https://hub.docker.com/r/aswf/ci-base -- use :2022)

Our conan and cmake setup has only two dependencies, expat and opengl/system. I invoke conan on the CI machine like this:

conan install -s build_type=Release -pr:b=default --build=missing .

and that succeeds, and creates a bunch of files in build/Release/generators. But then I can't figure out the right invocation of cmake. I know 3.19.3 is too old for presets, so following the suggestion in the conan output, I try this:

cmake --trace-expand . -G "Unix Makefiles" -DCMAKE_TOOLCHAIN_FILE=$(pwd)/build/Release/generators/conan_toolchain.cmake -DCMAKE_POLICY_DEFAULT_CMP0091=NEW -DCMAKE_BUILD_TYPE=Release

but that fails with this error:

CMake Error at HostSupport/CMakeLists.txt:7 (add_library):
  Target "OfxHost" links to target "expat::expat" but the target was not
  found.  Perhaps a find_package() call is missing for an IMPORTED target, or
  an ALIAS target is missing?

From looking at the --trace=expand log, I think maybe cmake is running /usr/local/share/cmake-3.19/Modules/FindEXPAT.cmake rather than the conan-generated package (I never see any references to generators/*expat* in the log).

I get the same result using conan build . because it runs the same cmake command.

Is there some way to invoke cmake to make it use my conan-generated FindEXPAT.cmake or whatever it should be finding from the generators subdir? I did try -DCMAKE_PREFIX_PATH=$(pwd)/build/Release/generators and -DCMAKE_MODULE_PATH=$(pwd)/build/Release/generators but got the same result as above.

Have you read the CONTRIBUTING guide?

• [X] I've read the CONTRIBUTING guide

[memsharded]

Hi @garyo

Thanks for your report. It is a bit difficult to know exactly what could be happening without being able to reproduce, it would be good to have something like a CMakeLists.txt.

One of the things that I suspect could be related to something like this:

find_package(some_pkg CONFIG REQUIRED)

add_library(mylib <sources>)
target_link_library(mylib PRIVATE some_pkg::some_pkg)

add_executable(myexe <exe sources>)
target_link_library(myexe PRIVATE mylib)

The key is that the first linkage should be target_link_library(mylib PUBLIC some_pkg::some_pkg)

Definitely CMake 3.19 shouldn't be an issue, we test everything with down to CMake 3.15. Do you think it would be possible to have something we can reproduce on our side? Thanks!

[garyo]

Aha -- (as always, I figured it out right after posting this!) our CMakeLists.txt was hard-coding CMAKE_MODULE_PATH which was overriding the one set by the conan-generated toolchain. Once I switched to list(APPEND CMAKE_MODULE_PATH ...) it all started working with the old-style cmake invocation. Thanks for the quick reply, and sorry for the noise.

[memsharded]

Thanks for following up! Happy that you found the issue :)