[libcxx-commits] [PATCH] D119255: [runtimes] Remove support for standalone builds

Thu Feb 10 13:05:12 PST 2022

ldionne added a subscriber: phosek.
ldionne added a comment.

In D119255#3310444 <https://reviews.llvm.org/D119255#3310444>, @simoll wrote:

> Thanks. We are testing this now and will switch to a runtimes build soon.

Sure! Let me know if you run into issues with this. Remember, you want to be rooting your CMake invocation at `<monorepo>/runtimes`, not `<monorepo>/llvm`. The former is going to build similarly to the previous standalone build, and the latter would cause Clang to be bootstrapped first, which is a bigger change from what you were doing previously.

In D119255#3310667 <https://reviews.llvm.org/D119255#3310667>, @mgorny wrote:

> For the record, I just want to say that this sucks a lot for Gentoo and I'm really unhappy with the recent trend of ignoring other people's effort and destroying their use cases for one's own convenience. But I guess I have to live with it. It's just sad how much effort I've wasted fixing things every time standalone builds were broken, and in the end the working code is being broken for the sake of preventing others from maintaining standalone builds. In the end, we'll manage but probably at the cost of preventing our users from installing GNU libunwind and libc++ simultaneously but I guess people using binary distros just don't care that could be a better way.

I'm going to stay nice despite the accusatory tone of your message.

This change has been cooking for a long time, just like the upcoming removal of `LLVM_ENABLE_PROJECTS` for libcxx, libcxxabi and libunwind. This is not about "convenience" or breaking people just for the sake of it, as this commit might make you think. The reason why this commit is just adding `message(FATAL_ERROR` is because I wanted to keep the cleanup that will follow separate, in case this needed to be reverted.

Standalone builds are a pain to maintain. We need to tie the various projects together with a bunch of CMake variables, which adds a bunch of complexity. Instead, it's much easier if we can assume that things are laid out in a specific way in the repository. We'll be able to reuse a bunch of code for all the runtimes, and as a result make things simpler, easier to maintain and even more customizable in the future. I already have a bunch of ideas that can't be implemented right now because we'd have to triplicate the code in libcxx, libcxxabi and libunwind, which is just terrible.

Also, there is a common misconception about the removal of standalone builds. Removing standalone builds DOES NOT MEAN that we remove any customizability in your builds. You can still build just one project, nothing changes here. Please go and read our documentation on the supported ways to build: https://libcxx.llvm.org/BuildingLibcxx.html#the-default-build. If you want to build just libcxx, you can always do this:

  cmake -G Ninja -S <monorepo>/runtimes -B build -DLLVM_ENABLE_RUNTIMES="libcxx"
  ninja -C build cxx

(You'll need to pass the usual options for specifying the ABI library to use unless you also add `libcxxabi` to `LLVM_ENABLE_RUNTIMES`)

This is basically the same as a standalone build -- it doesn't build Clang, it doesn't build libc++abi, it doesn't build libunwind. It builds libc++ only, and gives you exactly the same control you had before on your build. If you want to build libc++abi or libunwind separately, you can run three of these builds with a different `LLVM_ENABLE_RUNTIMES=<foo>` each time, like you do for standalone builds. It's cumbersome to do that, but nobody's going to stop you. If there is some customizability you think you are losing with the new way to build, please let me know concretely what it is, and we'll try to support it. But I don't think there should be anything that you could do with standalone builds that you can't do anymore, except laying out the projects in arbitrary ways (but dropping support for that is the whole point, since it's hard to support and provides virtually no benefit).

In D119255#3312150 <https://reviews.llvm.org/D119255#3312150>, @serge-sans-paille wrote:

>> Standalone build have been deprecated for some time now,
>
> @ldionne : can you point me to the thread / documentation that states so? I can find https://discourse.llvm.org/t/standalone-build-for-clang-lld-fix-or-remove but this thread doesn't lead me to the same conclusion.

There was discussion about this in 2020 here <https://lists.llvm.org/pipermail/llvm-dev/2020-October/145997.html>, and then various patches by @phosek, myself and others over the last 1.5 years to work towards what we're finally doing today. The direction we ended up taking for the "unified standalone build" is basically what you do when you root the CMake invocation at `<monorepo>/runtimes`.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D119255/new/

https://reviews.llvm.org/D119255