Streamlining support for standalone builds

Hi, everyone.

I’d like to try working on streamlining the support for standalone builds of different LLVM projects (e.g. clang, lld…). In order to do that, I’d like to first hear from other users of standalone builds about their use cases.

Since sometimes the term seems confusing, by standalone build I mean a build of e.g. clang that uses installed LLVM files and does not have access to the object tree created while LLVM was built. In other words, a setup like:

  1. Building, testing and installing LLVM first, then removing the build directory.
  2. Building, testing and installing Clang against installed LLVM, then removing the build directory.
  3. Building, testing and installing LLDB against installed LLVM and Clang…

We are using standalone builds in Gentoo for a few years now. I’ve been submitting some patches but to be honest, I’m not even sure who added the initial support to the LLVM projects. Since Gentoo is a source distribution and doesn’t distribute official binary packages, it means that the majority of our users end up building LLVM from source. The use of standalone builds sometimes makes a huge difference because it means that our users need only to build as much of LLVM projects as they actually need.

Right now, the support for standalone builds involves a lot of duplication. See e.g. clang support, lld support, mlir support, lldb support… Besides code that could potentially be deduplicated, there are different approaches to the same problems, and code that basically feels like hacks (e.g. defining variables that LLVM normally defines as part of in-tree build). At least we’ve gotten rid of (most of) the support for llvm-config.

I’ve already started streamlining some of it by moving cmake_policy() settings into a shared file. At a first glance, things like CMAKE_CXX_STANDARD setting could also go there.

Another thing I’d like to do is moving some of the common logic like setting LLVM_INCLUDE_DIRS into a file inside installed LLVM CMake modules. In other words, instead of redefining them inside every project, one would just do something like:


and similarly, clang would install ClangStandalone that would provide clang-specific defines for projects using it (e.g. LLDB).

Besides reducing duplication, this should also be less error-prone.

WDYT? In particular, if someone is using standalone builds right now, could you tell me whether there is something you’re specifically relying on that I should be careful not to break? Also, I’d use a list of people to add as reviewers on relevant patches.

Hey @mgorny !

Thanks for volunteering! Big +1 from me.

I think that this was discussed not so long ago: I am assuming that this is meant to build on top of what @tstellar worked on?

I believe that some Flang developers use it in their workflows, see Building flang standalone. IIRC, @psteinfeld wrote that particular section of the documentation :slight_smile: There’s also flang-aarch64-out-of-tree that is maintained to test Flang standalone builds.

While I don’t use standalone builds personally, I very supportive of everything that makes our CMake scripts more uniform and cleaner and I really appreciate you proposing this.


I actually haven’t seen that one while searching for prior discussion (mea culpa, I guess) but yes, working on top of that makes sense.