llvm dev - Jan 2019 - GN build roundtable summary; adding GN build files to the repo

A short update: All the build files I had locally are now upstreamed in
llvm/utils/gn. If you want to give it a try, see llvm/utils/gn/README.rst (
https://reviews.llvm.org/D56375 is pending to remove the "nothing works
yet" disclaimers). It's still a bit rough around the edges, but on my
Mac
and Linux boxes check-clang check-lld check-llvm all work, with the
AArch64, ARM X86 targets hooked up (and PowerPC and WebAssembly out for
review).

GN is much more convenient to use if a small and hidden .gn file is in the
root directory. I discovered that the new monorepo has a way to add files
in the root dir, so I'm planning to move llvm/utils/gn/.gn to the root
directory in https://reviews.llvm.org/D56419 . This does _not_ mean that
the GN build is any more supported than before (i.e. "not supported at
all"). I thought this was a pretty harmless change but I got pushback
almost immediately after sending it out, so I'd like to mention it here so
that it doesn't look like I'm trying to sneak this in.

On Wed, Oct 31, 2018 at 2:18 PM Nico Weber <thakis at chromium.org> wrote:
> Hi,
>
> 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,...}.
>
> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190107/2355b4cf/attachment.html>