-
Notifications
You must be signed in to change notification settings - Fork 978
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[feature] CMake integration: proof of concept of sysroot + CMakeDeps priority #12478
Comments
I think with CMake there isn't currently a solution that covers all cases, but there is potential for one. When not cross compiling,
When we are cross compiling (
This search order can cause problems if the sysroot contains things that we intend to consume from Conan instead. For example, it is typical that a target system will contain things like There are also going to be libraries that one won't be providing from Conan, but will rely on the Obviously if one knows which libraries are to be provided by Conan and which libraries are part of the "system" - then one can alter the The "ideal" search order would be:
If CMake had a fourth option in addition to |
You're in luck, but it's very new - part of the CMake 3.24 dependency provider machinery: see CMAKE_FIND_PACKAGE_REDIRECTS_DIR, introduced for exactly this purpose. |
Not quite - it actually never searches "in the SYSROOT" per se. Rather, it takes every path it would have searched, in the order it would have searched them, prefixing each with the sysroot (and, if not found there, with other entries in CMAKE_FIND_ROOT_PATH). CMAKE_PREFIX_PATH isn't first, but it is pretty early (only PackageName_ROOT cache keys or environment variables are earlier). So one workaround (that I've used) is to bind-mount the CONAN_USER_HOME at that same path within the sysroot, so that it, and thus conan's build folders, are found during this prefixed search. |
that might be confusing, and it needs to be distinguish, for cross-compiling, especially.
these are traditional values, now CMake variables are mapped to this:
in general, I believe nothing is needed from conan's side, expect population the |
We are using Conan to build libraries and applications for regular desktop machines running Linux, MacOS or Windows, but also for embedded devices running a distribution built with Yocto. In our Conan recipes we have conditions that require OTS packages only, when not cross-compiling. Otherwise, they are expected to be shipped with the Yocto SDK, which by defaults sets this in its toolchain file:
We add Yocto's toolchain file The
During our investigation to solve this issue, we came to following conclusions:
For Conan we considered two options:
|
It is not fully clear, maybe not enough tested:
What would be the best way to integrate? The
conan_toolchain.cmake
can include the vendor toolchain.cmake, or an intermediate one from the user, but does this guarantee behavior if the vendor toolchain changes priorities of CMake for finding package only in itself?cc / @maikelvdh
The text was updated successfully, but these errors were encountered: