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

Thu Nov 1 07:06:51 PDT 2018

Hello everyone

Vedant, thanks for bringing this to my attention. From my work on LLDB,
I agree with all your points.

> I think it's very valuable that we have one shared build system.
Most of us don't want to spend their time on build system tasks, right?
Supporting a second build system in-tree will inevitably increase our
amount of attention on it. We should be pragmatic and not jump on new
developments easily.

> If you'd like to check in GN files, my strong preference would be to
> accompany that with a plan to phase cmake out.
So, would it be a good idea to phase out CMake? I rarely meet people who
are happy with CMake, but I think the bar is still very high, because:

* The community developed a collective understanding of CMake with all
it's strengths and pitfalls. With GN most of us had to learn a new language.
* There is a lot of valuable documentation and tutorials about LLVM and
CMake. It will take time and effort for GN to catch up.
* CMake is the de-facto standard for private and cross-corporation C++
projects (and rising [1]).
* Kitware is not a stakeholder in LLVM and CMake not tailored to
anyone's specific needs.

[1] Rank 6 fastest growing languages on GitHub:
https://octoverse.github.com/projects

> 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.
+1 and it's been the same for previous projects I worked on. Is there a
good example where multiple build systems actually coexist well?

> Replicating complex bits of build system logic also is a chore
Yes, it needs knowledge of the pitfalls for both of them + runnable
setups for the various configurations.
Speaking for myself, it takes a lot of time and mood.

Am 31.10.18 um 23:10 schrieb Nicolai Hähnle via llvm-dev:
> On 31.10.18 19:18, Nico Weber via llvm-dev wrote:
>> 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. 
This seems very reasonable as long as GN is not adopted as the one an only.
Also it's the best way to make sure it's fully maintained by GN users.

Am 01.11.18 um 00:28 schrieb Zachary Turner via llvm-dev:
> One thing to think about is that generated IDE projects from CMake are
> less than ideal.  In fact I actually made a post about this a few
> weeks ago.
Note that IDE vendors are working on direct CMake support as well, e.g:
* VS2017 & Qt Creator:
https://blog.kitware.com/cmake-e-server-improves-visual-studio-and-qt-creator-ides/
* CLion: https://www.jetbrains.com/help/clion/project-models.html

Best
Stefan

Am 01.11.18 um 01:22 schrieb Vedant Kumar via cfe-dev:
> Hi all,
>
>> On Oct 31, 2018, at 11:18 AM, Nico Weber via llvm-dev
>> <llvm-dev at lists.llvm.org <mailto: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
>
>>
>> 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.
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org <mailto: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/20181101/281154bc/attachment.html>