[libcxx-dev] [llvm-dev] [RFC] A vision for building the runtimes

[Chris Tetreault via libcxx-dev]

How is CMake rigged to build these libs using the just-built Clang? If this functionality is built into the current build system, can you kindly point me to where this is rigged up? Is add_custom_command being used?

Thanks,
   Christopher Tetreault

-----Original Message-----
From: Louis Dionne <ldionne at apple.com>
Sent: Friday, October 23, 2020 11:45 AM
To: Chris Tetreault <ctetreau at quicinc.com>
Cc: Libc++ Dev <libcxx-dev at lists.llvm.org>; LLVM Dev <llvm-dev at lists.llvm.org>; Petr Hosek <phosek at chromium.org>
Subject: [EXT] Re: [llvm-dev] [RFC] A vision for building the runtimes



> On Oct 23, 2020, at 12:48, Chris Tetreault <ctetreau at quicinc.com> wrote:
>
> Forgive me if this is obvious to everybody but myself, but I just want to be clear on the new proposed behavior for monorepo builds:
>
> What happens if I do `cmake ... -LLVM_ENABLED_PROJECTS="all" ...`? I assume that prior to your change, I would get the runtimes (built using the system compiler), but now I will not?

I believe the behavior here should be equivalent to -DLLVM_ENABLE_PROJECTS=<all-except-the-runtimes> -DLLVM_ENABLE_RUNTIMES=all.

Basically, I would suggest that we make the current runtimes/toolchain build the default way to build libc++, libc++abi and libunwind. I'm not sure how compiler-rt works today so I'm not sure this is necessary -- I think it already builds using the just-built Clang but I wouldn't bet on it.

This way, you'd get a correctly built toolchain with the runtimes by default when you checkout LLVM, without having to care about any of this. Currently, you get Clang, LLVM and friends built against the system compiler, and the runtimes too (which may or may not work as you intend -- I can easily craft a configuration that won't work).


>
> What happens if I do `cmake ... -LLVM_ENABLED_PROJECTS="...;[some runtime];..." ...`? I assume that prior to your change, I would get the requested runtime, but now I will get an error?

Currently, that would build that runtime with the system compiler, as a subproject of LLVM. This "works", but it's not great because LLVM enables a bunch of flags globally and those can trip up the runtimes, as explained in the OP.
I would suggest that we make it an error to try and build one of libcxx, libcxxabi and libunwind with `llvm/CMakeLists.txt` as the root.

> Basically, "if I just want to hack on LLVM, do I need to change my workflow?"

I would expect not, however you'd go from building the runtimes with the system compiler to the runtimes with the just-built compiler (i.e. the correct way).

>
> I also wonder if the runtimes build really needs the tip of master in order to build correctly. Could you just make it an error to build with a compiler that doesn't support a new enough C++ standard? Sure, if I'm trying to compile with whatever version of GCC comes with Debian, it won't work, but if I'm running the latest GCC or a fully patched visual studio 2019?

They don't technically need trunk, but they do need something recent. And it's usually not just about what Standard a compiler pretends to support, but more often about what intrinsics are supported, etc. Also, we don't gain anything from supporting significantly older compilers if the default CMake setup does the right thing and builds it with the just-built compiler.

If you wanted to build the runtimes with something else than the just-built Clang, that's entirely fine. You could do that using the Unified Standalone build I proposed -- this is actually what we do right now at Apple, since we don't ship libc++/libc++abi as part of the toolchain (we ship it as part of the OS, and we build it with a couple-months-old Clang).

Louis