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

[Zachary Turner via llvm-dev]

On Wed, Oct 31, 2018 at 5:22 PM Vedant Kumar <vsk at apple.com> wrote:

> Hi all,
>
> On Oct 31, 2018, at 11:18 AM, Nico Weber via llvm-dev <
> llvm-dev at lists.llvm.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.
>
>
> I think it's very valuable that we have one shared build system. If you'd
> like to check in GN files, my strong preference would be to accompany that
> with a plan to phase cmake out.
>
> I really don't mean to be flippant here -- I'm in awe of the work you've
> already done to set up GN files, and I know transitioning away from cmake
> would be a massive amount of work. Hear me out :)
>
> My perspective comes from having worked on lldb for a while. lldb has two
> build systems (xcodebuild & cmake). I suppose opinions differ on whether
> that works well. Speaking for myself, having two build systems has been a
> massive source of frustration. I regularly see commits which break one of
> the two systems because of course they do. No one wants to test their
> commit a second time against a build system they don't really use.
> Replicating complex bits of build system logic also is a chore -- I've CC'd
> Stefan who might be able to say more about that.
>
> My concern is that introducing gn files into llvm will cause a bit of a
> fracture. If the policy is that cmake users don't have to worry about
> breaking the gn build, I think gn users would be less inclined to fix the
> cmake build. If most developers decide to switch to gn, that would leave
> cmake adopters with a higher (possibly unmanageable) maintenance burden.
> It's also confusing for new users, as they already have a lot of different
> ways of checking out and building.
>
> I know your plan is to have the maintenance burden of gn files placed on
> gn users, and that you haven't experienced an unmanageable number of breaks
> over the past 8 months. In lldb (a lower volume project), I actually do
> think the constant build breaks are hard to manage. And I'm just not sure
> the temptation to only update gn files could be resisted, as "works in my
> build system" tends to shut down conversations. I'm worried the same thing
> would happen in llvm.
>
> best,
> vedant
>

Personally I am also skeptical of the value of having 2 different build
systems, for many of the same reasons you have elborated here.  One thing I
actually find might be worth exploring is the quality of the IDE-generated
projects by gn, especially the Xcode projects.  Having a build system
(whether it be CMake or gn or something else is irrelevant) that can
generate high quality Xcode IDE projects is -- to my understanding -- a
pre-requisite for getting LLDB off of the hand-maintained Xcode project.

Would you be willing to try out gn's generated Xcode project (I'm told this
is supported, but I haven't tried it since I don't have a Mac) either with
LLVM or LLDB (if the current build files support LLDB) and do a usability
comparison of the generated projects?

This is the one killer feature that would be a strong win over CMake that
we currently have no clear path to ever making headway on.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20181031/f1bef40c/attachment-0001.html>