Open rturrado opened 4 months ago
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.
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
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.
@jcar87 maybe we want to consider adding CMAKE_PROGRAM_PATH
definition to the provider?
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
?
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=...
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 !
Yes, exactly, the CLion plugin uses the cmake-conan
integration, so this is why I moved this to this project.
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 https://github.com/conan-io/cmake-conan/pull/626
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
).
Indeed we have :) Thanks for reporting these things - little by little this integration is proving to be robust :D
Hi there!
I have this project, libqasm, which is doing:
at
conanfile.py
. Later on, atCMakeLists.txt
, it tries to find a package, and a binary exported by that package:The logs show that the package is found, but not the binary:
However, the binary is correctly found when building from the command line.
These are my CMake options (CLion > CMake tab > Settings):
May I be missing something from the CLion Conan configuration, a path where to search for the executable or something?
Many thanks!