Add a --cmakedir option to llvm-config that returns the correct path to
built/installed CMake modules (i.e. lib/cmake/llvm). This is mostly
intended as a convenience option for stand-alone builds of other LLVM
projects that frequently reconstruct LLVM_CMAKE_PATH after querying
llvm-config.
Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
I'm curious what your use case for this is. I actually think this, and your other patch are moving in the opposite direction from how I would like to see this move.
I'd like to see us move in the direction where we can rely on the CMake find_package mechanism entirely instead of on llvm-config.
My use case is that I'm working on adding x32 support and some of the runtime packages (libunwind, libcxx, libcxxabi) look for LLVM cmake files in LLVM_LIBDIR_SUFFIX. I don't want to unnecessarily copy them to libx32 when those packages don't really depend on LLVM itself and therefore are entirely happy with the native files from lib64.
While this could be solved in a number of ways, this seemed the simplest and most in-line with how other directories are obtained.
However, it might be cleaner to split the CMake files between arch-specific and arch-independent, and install them both to lib* and share appropriately. If we want to go this route, indeed --cmakedir would be conflicting with the goal of having two directories to add.
I'd like to see us move in the direction where we can rely on the CMake find_package mechanism entirely instead of on llvm-config.
I don't really see one preventing the other. I can look at the find_package solution at some point but right now I certainly don't have time for that.
@beanz, thinking about this more: how should the find_package mechanism handle the distinction between packages actually needing LLVM components like libraries, and packages purely needing LLVM cmake files?
And more generally: would you find it acceptable to alternatively just add cache variable controlling CMake file location for now?
I think moving to find_package is a nice long term thing, but for existing users of llvm-config, this seems like a perfectly reasonable improvement.
To be honest, I'm not so sure anymore about this change. Thinking about it again, right now we enforce ABI match between LLVM and revdeps by using LLVM_LIBDIR_SUFFIX. If we start getting CMake path straight from llvm-config, users will be required to explicitly override LLVM_CONFIG for each ABI, or otherwise e.g. 32-bit clang could be built using configuration from 64-bit one.