Page MenuHomePhabricator

[llvm-config] Add --cmakedir to obtain CMake module location
ClosedPublic

Authored by mgorny on Nov 20 2016, 2:32 AM.

Details

Summary

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.

Diff Detail

Repository
rL LLVM

Event Timeline

mgorny updated this revision to Diff 78655.Nov 20 2016, 2:32 AM
mgorny retitled this revision from to [llvm-config] Add --cmakedir to obtain CMake module location.
mgorny updated this object.
mgorny added reviewers: beanz, rnk, chapuni, chandlerc.
mgorny added a subscriber: llvm-commits.
beanz edited edge metadata.Nov 20 2016, 9:43 PM

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.

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.

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?

rnk accepted this revision.Jan 4 2017, 10:40 AM
rnk edited edge metadata.

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.

This revision is now accepted and ready to land.Jan 4 2017, 10:40 AM

@rnk, thanks for the review. Could you check D26900 as well? That's the clang-end of this change.

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.

Disregard that. We need to override LLVM_CONFIG e.g. for --libdir anyway.

This revision was automatically updated to reflect the committed changes.