[llvm-dev] GN build roundtable summary; adding GN build files to the repo

[Dean Michael Berris via llvm-dev]

> 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