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

Tue Nov 6 11:54:52 PST 2018

Awesome. I'm happy with moving the .rst file into that directory and not
have it on the public website. I'll try to make a patch that lands enough
scaffolding to build `not` in the next few days, and then I'll land the
other build files I have through the regular build process after that.
Unless someone feels strongly, I'll go with Justin's suggestion of
llvm/utils/gn/...

On Tue, Nov 6, 2018 at 12:20 PM David Blaikie <dblaikie at gmail.com> wrote:

> Yeah, I don't feel super strongly about the name or location if it's a
> single directory entry point. Not sure if/where it should be documented (if
> it needs web documentation - rather than or in addition to a README in that
> directory) - don't really want to muddy the waters in the official docs as
> others have mentioned. I'm OK with it going in-tree under those conditions,
> FWIW.
>
> On Tue, Nov 6, 2018 at 3:10 AM Nico Weber via cfe-dev <
> cfe-dev at lists.llvm.org> wrote:
>
>> The value in having them somewhere in-tree is that it's easier for people
>> collaborate on these files, and it's way lower setup overhead if someone
>> wants to try it out. If people prefer llvm/util over llvm/experimental,
>> that's fine with me.
>>
>> There would only be a single directory that will contain build files for
>> all of llvm, clang, lld, etc. The build files would be in
>> llvm/whatever/gn/tree/{llvm,clang,lld,...}/... ("tree" can be any name).
>> That's not the most natural way to use gn, but I agree that having BUILD.gn
>> files scattered all over the tree could make it look like gn is supported
>> at some level.
>>
>> If adding the files in an isolated directory still ends up being
>> confusing in practice, we can move them out at that point. But I'd like to
>> start with the simpler way and see if that's good enough.
>>
>> On Mon, Nov 5, 2018 at 8:22 PM Justin Bogner <mail at justinbogner.com>
>> wrote:
>>
>>> Nico Weber via llvm-dev <llvm-dev at lists.llvm.org> writes:
>>> > If I read this correctly, there isn't much opposition to landing the gn
>>> > files as long as it's very clear that regular devs aren't supposed to
>>> > update them and that it's clear that they're experimental
>>> >
>>> > The main concerns I've heard so far:
>>> >
>>> > - Having two build systems is confusing. I can see this, but I think
>>> > putting the gn files below llvm/experimental/gn (instead of right into
>>> the
>>> > source, like I currently have) and updating GN.rst to explicitly say
>>> > "Reviewers should not ask patch authors to update gn files in addition
>>> to
>>> > the cmake files" will address this.
>>>
>>> I haven't been following this discussion and I don't really know
>>> anything about GN, but I'm not very convinced by this.
>>>
>>> I'm opposed to adding a second build system in general. We all remember
>>> having two build systems before and it's a pain keep track of as well as
>>> a documentation nightmare in telling people yet more ways to do
>>> things. Our docs are already confusing enough given that we currently
>>> support two completely different layouts of source directories for
>>> cmake.
>>>
>>> I suppose putting it somewhere under utils/ as a kind of tool for people
>>> who want to use it like we do with text editor support and such things
>>> wouldn't be the end of the world, but the value of that is pretty
>>> limited if you're explicitly opting them out of community maintenance.
>>>
>>> If the build files can be maintained in their own directory, and will
>>> only be updated by some set of people who are using them, why not track
>>> them in a separate source repo? This way when a breaking change happens
>>> your build system could still be made to work for the commits in between
>>> the time that happens and the GN files are updated, since you'd be
>>> maintaining a separate mapping of which versions work together.
>>>
>>> > - Having a few people care about the GN build means these people won't
>>> > improve the cmake build. I think this has some merit (but I did clean
>>> up
>>> > parts of the cmake build a bit while reading all our cmake code to
>>> create
>>> > the gn build for example, and I have several ideas about improving the
>>> > cmake build I want to implement at some point; and it's also not a
>>> given
>>> > that the folks who may or may not end up working on the GN build would
>>> have
>>> > worked on the cmake build). However, this is true independently of
>>> where
>>> > the GN build files are stored.
>>> >
>>> > - GN isn't a cmake replacement, for distro reasons and whatnot. I
>>> > wholeheartedly agree with this. Maybe GN will become better here, but
>>> cmake
>>> > is ubiquitous _today_, and it's backed by a company who's interested in
>>> > keeping it around, so it will be around for a long time. I think this
>>> is
>>> > cmake's biggest strength. That's why I'm not proposing on replacing the
>>> > cmake build. If the GN build at some point is way better (compiler-rt,
>>> > lldb, etc added; out-of-tree build support; GN itself gets a real
>>> distro
>>> > story; ...) then this _may_ be different in a few years, at which
>>> point we
>>> > could reconsider. I think this is unlikely to happen.
>>> >
>>> > (I still don't see that any of these problems are being solved by
>>> having
>>> > this in an overlay or a separate fork.)
>>> >
>>> > And again, It's a real possibility that we check this in and it turns
>>> out
>>> > the people who are interested in don't feel it's all that useful, it
>>> > bitrots, and we delete it again. That's cool, no harm done. I think we
>>> > should have a very high standard for replacing the supported build
>>> system
>>> > (cmake), but I think it's cool to have a low bar for people
>>> experimenting
>>> > with unsupported build systems, as long as they get deleted if not
>>> used. If
>>> > someone wanted to a, say, llvm/experimental/meson to see how that would
>>> > feel, I think that'd be super cool too for example.
>>> >
>>> > On Fri, Nov 2, 2018 at 2:06 AM Dean Michael Berris <
>>> dean.berris at gmail.com>
>>> > wrote:
>>> >
>>> >> I think this is how, after moving to a monorepo, it may be feasible to
>>> >> get this in a separate fork.
>>> >>
>>> >> Granted the Git Monorepo + GitHub happens, we can even make it so that
>>> >> the GN build is a branch on the official git repository, which can
>>> >> track the mainline development.
>>> >> On Fri, Nov 2, 2018 at 3:49 AM David Blaikie via llvm-dev
>>> >> <llvm-dev at lists.llvm.org> wrote:
>>> >> >
>>> >> > Any easy way to do this as some kind of overlay, so they GN files
>>> >> wouldn't live in the LLVM repository, but in a separate one?
>>> >> >
>>> >> > (this might avoid some of the community discussion - though would
>>> >> perhaps still likely have the issue I see as most significant: With a
>>> >> sufficient number of developers using GN, the rate of build breaks
>>> due to
>>> >> those developers missing CMake file updates might rise to be a bit of
>>> a
>>> >> drag on the LLVM project - though I don't think that's likely to ever
>>> be a
>>> >> huge deal, just an annoyance)
>>> >> >
>>> >> > On Wed, Oct 31, 2018 at 11:19 AM Nico Weber via cfe-dev <
>>> >> cfe-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.
>>> >> >>
>>> >> >> 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.
>>> >> >> _______________________________________________
>>> >> >> cfe-dev mailing list
>>> >> >> cfe-dev at lists.llvm.org
>>> >> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>> >> >
>>> >> > _______________________________________________
>>> >> > LLVM Developers mailing list
>>> >> > llvm-dev at lists.llvm.org
>>> >> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>> >>
>>> >>
>>> >>
>>> >> --
>>> >> Dean
>>> >>
>>> > _______________________________________________
>>> > LLVM Developers mailing list
>>> > llvm-dev at lists.llvm.org
>>> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20181106/ab4cf898/attachment.html>