[llvm-dev] GN build roundtable summary; adding GN build files to the repo (original) (raw)

Dean Michael Berris via llvm-dev llvm-dev at lists.llvm.org
Wed Oct 31 16:38:44 PDT 2018

On 1 Nov 2018, at 10:24, Petr Hosek via llvm-dev <llvm-dev at lists.llvm.org> wrote:

I'll volunteer to maintain the GN files if the community is in favor of having those in the tree. I mentioned that I'd consider using GN build on bots (and Nico said the same for Chromium) during the roundtable discussion, but what I meant was for our downstream bots. If there are upstream bots using GN, they should be FYI only bots (I don't know if there are any such bots in LLVM already) that don't send out any notifications on breakages. There are other advantages to GN but those are not immediately obvious. GN has a first-class concept of a toolchain and it allows "applying" these toolchains on dependencies, so you can express the fact that a particular dependency should be built with a different toolchain, which could be a completely different compiler or just a different set of flags. This is an extremely powerful concept that would be useful for things like runtimes build. Right now, those require re-running CMake multiple times for each target you want to build runtimes for, so take the number from above responses and multiply that by the number of targets you're supporting in your toolchain and suddenly it may become significant (it definitely is in our case).

This.

Although I don’t use GN myself, it would be great if we can somehow port the compiler-rt unit-test generation process to use the “just-recently-built toolchain”, it would break up the non-parallelism of those actions.

Regarding the experimental status, I think we need to get the GN build to the point where it provides parity with the CMake build and handles all common use cases and workflows before we can have that discussion.

+1 from me.

-- Dean

More information about the llvm-dev mailing list