You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
See also the thread started by by @SpaceIm in #10186 (comment)_
I didn't see this until looking at the 1.45 changelog, and I figure the review of a month-old merged PR is not best place to raise additional concerns.
setting CMAKE_FIND_ROOT_PATH_MODE_* to BOTH gives me a lot of heartburn. I get the argument that BOTH will still check the places that ONLY would have cheked first, so if ONLY would have succeeded, BOTH gives the same answer. But CMakeToolchain goes with CmakeDeps, which writes package-config.cmake files. So if I'm using find_library (or a FindLibFoo.cmake MODULE mode find_package), it's probably for something that does not come from a conan package. And I've been bitten quite a few times when a library was missing in the embedded sysroot, usually some transitive thing I didn't know I should think about, and BOTH resulted in CMake just finding something from the build environment. And in fact that may very well even link without error: if the host sysroot is x86-linux and the build environment is an ubuntu with 32-bit multiarch packages installed, gcc isn't necessarily going to see anything wrong. Wrong versions, wrong toolchains, mismatched glibc, etc are still quite like;,, but you might still produce a binary full of nasal demons without so much as a warning from the linker.
I see the problems with using CMAKE_FIND_ROOT_PATH, though - conan doesn't really want to re-root everybody else's path's either.
My current solution has been to bind mount the conan cache at the same location inside the sysroot, so that it's found prefixed, but that's noo ideal either.
I wonder if CMake could be convinced to implement something like a CMAKE_FIND_ONLY_PATH that was kind of the the opposite of CMAKE_IGNORE_PATH for conan 2.0 to use. It could just be a ;-list of prefixes that did not introduce any additional search locations, but made paths (from things like CMAKE_LIBRARY_PATH) eligible to match in CMAKE_FIND_ROOT_PATH_MODE_* ONLY if they intersected with it. If that existed, conan could list the root paths of packages found in the host context; and if necessary to support older CMake versions, you could still set "BOTH" mode for them (but then only old versions would have to take the risk of accidentally picking up non-conan libraries from the build environment).
The text was updated successfully, but these errors were encountered:
it just did like there is kind of a CMake gap here - no good way to say "these build-system paths contain host binaries" without using CMAKE_FIND_ROOT_PATH, which has all kinds of other consequences (re-rooting all other searches)
See also the thread started by by @SpaceIm in #10186 (comment)_
I didn't see this until looking at the 1.45 changelog, and I figure the review of a month-old merged PR is not best place to raise additional concerns.
setting CMAKE_FIND_ROOT_PATH_MODE_* to BOTH gives me a lot of heartburn. I get the argument that BOTH will still check the places that ONLY would have cheked first, so if ONLY would have succeeded, BOTH gives the same answer. But CMakeToolchain goes with CmakeDeps, which writes package-config.cmake files. So if I'm using find_library (or a FindLibFoo.cmake MODULE mode find_package), it's probably for something that does not come from a conan package. And I've been bitten quite a few times when a library was missing in the embedded sysroot, usually some transitive thing I didn't know I should think about, and
BOTH
resulted in CMake just finding something from the build environment. And in fact that may very well even link without error: if the host sysroot is x86-linux and the build environment is an ubuntu with 32-bit multiarch packages installed, gcc isn't necessarily going to see anything wrong. Wrong versions, wrong toolchains, mismatched glibc, etc are still quite like;,, but you might still produce a binary full of nasal demons without so much as a warning from the linker.I see the problems with using CMAKE_FIND_ROOT_PATH, though - conan doesn't really want to re-root everybody else's path's either.
My current solution has been to bind mount the conan cache at the same location inside the sysroot, so that it's found prefixed, but that's noo ideal either.
I wonder if CMake could be convinced to implement something like a
CMAKE_FIND_ONLY_PATH
that was kind of the the opposite ofCMAKE_IGNORE_PATH
for conan 2.0 to use. It could just be a ;-list of prefixes that did not introduce any additional search locations, but made paths (from things like CMAKE_LIBRARY_PATH) eligible to match in CMAKE_FIND_ROOT_PATH_MODE_* ONLY if they intersected with it. If that existed, conan could list the root paths of packages found in the host context; and if necessary to support older CMake versions, you could still set "BOTH" mode for them (but then only old versions would have to take the risk of accidentally picking up non-conan libraries from the build environment).The text was updated successfully, but these errors were encountered: