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

[Nicolai Hähnle via llvm-dev]

On 31.10.18 19:18, Nico Weber via llvm-dev wrote:
> first things first: If you're happy with cmake, you can stop reading 
> now. Nobody is proposing that LLVM moves off cmake, and nobody is 
> proposing anything that's causing people using cmake more work.
> 
> At the LLVM conference, I gave a lightning talk [1] about using GN [2] 
> to build LLVM and clang. cmake is great for many use cases, but in my 
> opinion local day-to-day development isn't one of them. So I wrote GN 
> build files for LLVM and clang, enough to make `ninja check-llvm 
> check-clang check-lld` build everything needed for these three test 
> suites and that all tests pass. This works on Linux, Mac, Win hosts 
> targeting X86, ARM, AArch64. You can see them at [3].
> 
> I had been worried that it would be a lot of work to keep the build 
> files up to date, but I've been using this for all my LLVM/clang/lld 
> development the last 8 months, and it turned out to not be a big problem 
> -- LLVM's build files don't change very often, and GN build files are a 
> pleasure to work with in my opinion.
> 
> I gave the lightning talk just to talk about my personal workflow, but 
> there was a lot of interest. We had a roundtable on the next day, and 
> about 20 people said they'd be interested in using this for their 
> development too. The main request was that the .gn files are checked in 
> upstream, so that we can collaborate on keeping them working. Two to 
> three orgs even said they'd be interested in moving their buildbots to GN.
> 
> As mentioned at the top, the intention here is not to replace cmake, 
> only to offer an opt-in alternative for people who are interested in it. 
> Keeping the GN build going would be the responsibility of people using 
> it, not of the general LLVM community. If this fails to find use and 
> bitrots, we can easily remove it again.
> 
> Are there any concerns with checking in GN files? I've put some initial 
> docs for the GN build at https://reviews.llvm.org/D53944 ; it describes 
> what the GN build is and is not, what its advantages are (speed and 
> easier configurability), and some points about the philosophy behind the 
> LLVM GN build.
> 
> If folks are generally ok with GN files living in-tree, I'll start 
> sending patches for gradually adding gn files through the regular review 
> process.
> 
> If having a BUILD.gn file in every directory being confusing is a 
> concern, GN has the concept of a "secondary tree" so that all GN files 
> could be below llvm/gn/tree/{llvm,clang,lld,...}.

So maintain it in a separate repository.

Seriously, I am also working on another project (Mesa) which has a 
proliferation of build systems for historical and cultural (Android...) 
reasons, and it sucks.

Besides, how on earth are you using LLVM that cmake times are an issue? 
Given that cmake times seem to be the only argument you have in favor of 
GN...

I just measured the typical case (for LLVM only, debug build, all 
non-experimental targets enabled) by touching all files. cmake takes 5 
seconds to run, while the build as a whole takes about 5 minutes. (This 
is on Ubuntu 18.10, in case that matters.)

Cheers,
Nicolai



> 
> Cheers,
> Nico
> 
> 1: https://llvm.org/devmtg/2018-10/talk-abstracts.html#lt2
> 2: https://gn.googlesource.com/gn , https://is.gd/gn_intro
> 3: 
> https://github.com/llvm-project/llvm-project-20170507/compare/master...nico:gn 
> , click "Files Changed" to see the GN files.
> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> 

-- 
Lerne, wie die Welt wirklich ist,
Aber vergiss niemals, wie sie sein sollte.