find_program working when building from command line, but not when using the CLion Conan plugin

[rturrado]

find_program working when building from command line, but not when using the CLion Conan plugin

[memsharded]

Yes, exactly, the CLion plugin uses the cmake-conan integration, so this is why I moved this to this project.

[jcar87]

Hi @rturrado - thanks for reporting this. This is listed as one of the current limitations in the Readme, however we are currently working to implement support for this in #626

[jcar87]

Indeed we have :) Thanks for reporting these things - little by little this integration is proving to be robust :D

[memsharded]

Hi @rturrado

Thanks for your report.

I am not sure what would be the difference. What command line without CLion are you using?

The main difference could be if using the CMakeToolchain somehow, but if you are using CMAKE_PROJECT_TOP_LEVEL_INCLUDES="conan_provider.cmake" in the command line, it should behave the same.

If you are using conan install + cmake --preset on the command line, that would explain, because the presets use the generated conan_toolchain.cmake and that toolchain defines the necessary paths so find_program() finds executables.

[rturrado]

Hi @memsharded ,

Thanks for your quick reply. For the command line, I'm just building with conan build . <profile(s)> -b missing. For example:

conan build . -pr:a=conan/profiles/tests-debug -b missing

[memsharded]

That explains the behavior.

The conan build uses the full CMakeToolchain with the conan_toolchain.cmake, etc, that contains those paths so find_program() is found.

So this would be a cmake-conan issue, if it is possible or not to have find_program() work for tool-requires transparently.

To reproduce, you can run in the command line with -DCMAKE_PROJECT_TOP_LEVEL_INCLUDES argument, and it should be the same, so not specifically a CLion plugin issue.

I am moving this to cmake-conan repo, thanks.

[memsharded]

@jcar87 maybe we want to consider adding CMAKE_PROGRAM_PATH definition to the provider?

[rturrado]

Actually, I also do self.requires("tree-gen/1.0.6").

Excuse me, how can I pass that -DCMAKE_PROJECT_TOP_LEVEL_INCLUDES on to conan build?

[memsharded]

Excuse me, how can I pass that -DCMAKE_PROJECT_TOP_LEVEL_INCLUDES on to conan build?

It is not passed to Conan, but to cmake -DCMAKE_PROJECT_TOP_LEVEL_INCLUDES=...

[rturrado]

Well, this command line indeed reproduces the issue:

cmake -DCMAKE_BUILD_TYPE=Debug -DCMAKE_PROJECT_TOP_LEVEL_INCLUDES="conan_provider.cmake" -DCONAN_HOST_PROFILE="default;auto-cmake;/mnt/e/Programacion/code/c++/libqasm/conan/profiles/tests-debug-compat" -DLIBQASM_BUILD_TESTS=ON -DLIBQASM_COMPAT=ON -DASAN_ENABLED=OFF

I basically copied what I had in the CLion CMake settings (see screenshot attached), and added the CMAKE_BUILD_TYPE.

Thanks for your help @memsharded !

[rturrado]

Many thanks guys! Great work. I also noticed (quite some time ago) that you had fixed another issue I was experiencing with the CLion Conan plugin (the one that forced you to comment out the deps = CMakeDeps(self); deps.generate() lines in def generate(self) in conanfile.py).