If we ignore these variables, we end up always using the host
information for libxml2, when it is not appropriate. This makes builds
less hermetic than they should ideally be.
Details
Diff Detail
- Repository
- rC Clang
- Build Status
Buildable 19602 Build 19602: arc lint + arc unit
Event Timeline
Rui, I added you to this review (and the other corresponding one), as you reviewed ecbeckmann's original work here. Can you take a quick look at these? Thanks.
I think it might be more appropriate to pass NO_SYSTEM_ENVIRONMENT_PATH to find_package in case CMAKE_SYSROOT or CMAKE_CROSSCOMPILING are set? That way, we won't search the host system for libxml2 in those cases, but we'll still be able to find it in the custom sysroot or cross-compilation SDK if it's present.
Actually, I would imagine that if you're cross-compiling or using a custom sysroot, you should probably also specify CMAKE_FIND_ROOT_PATH and set CMAKE_FIND_ROOT_PATH_MODE_PACKAGE to ONLY, to limit all these searches to the desired directories?
(I'm actually playing around with a bunch of this stuff myself right now. I'm curious about your CMake setup for a custom sysroot or cross-compilation and what issues you've come across.)
Ah, the documentation is confusing, but CMAKE_FIND_ROOT_PATH and CMAKE_FIND_ROOT_PATH_MODE_PACKAGE only have an effect when using the config mode of find_package, whereas this invocation is using the module mode. That's a bummer, and definitely makes custom sysroots and cross-compilation harder than it should be. Sorry for the noise.
Okay, upon playing with this further, the following seems to do what I want (for a custom sysroot), and seems to be a pretty common pattern as well:
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY) set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY) set(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY) set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
CMakeLists.txt | ||
---|---|---|
191 | This isn't going to cause a problem for us since we always build LLVM against explicit sysroot even building for host, but we would still like to link against libxml2, except it should come from our sysroot rather than host. |
https://android.googlesource.com/toolchain/llvm_android/+/master/build.py is what we use to wrap all the CMake invocations that we do to create Android's toolchain. We have to currently iterate because we need to create multiple different runtimes for all of our supported architectures. I don't think we have hit many other problems. This is something that is only affecting some of our users, but I wanted to try to fix it better than "just uninstall libxml2".
As far as this patch goes, I am trying to experiment with those other variables you mentioned. If that is enough to solve all of our problems, I'm probably just going to abandon these two patches. CMake remains terribly painful to use, especially for these cross-compiling scenarios, which are not that well-documented in general.
Removed this in favor of the suggestions here. Setting the CMAKE_FIND_ROOT_PATH_MODE* variables does make this properly hermetic.
This isn't going to cause a problem for us since we always build LLVM against explicit sysroot even building for host, but we would still like to link against libxml2, except it should come from our sysroot rather than host.