<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>Lots of feedback! Sounds like several people are interested in this, which is cool.</div><div dir="ltr"><br></div><div dir="ltr">Trying to address a few points here:<div><br></div><div> > f these files exist in the repo, I could imagine that reviewers will </div><div>> reject patches that might/likely break the gn files.</div><div><br></div><div>I will make the language in <a href="https://reviews.llvm.org/D53944">https://reviews.llvm.org/D53944</a> stronger. Reviewers should not ask for this. If it helps, we could put the gn build files into a directory called "experimental" or similar.</div><div><br></div><div><div>> Do you think there will be some point in time that these files will be </div><div>> out of 'experimental' status?</div></div><div><br></div><div>Not anytime soon.</div><div><br></div><div>> Some folks who don't like GN or don't see the point.</div><div><br>That's fine, see first sentence in my mail :-)</div><div><br></div><div>> my strong preference would be to accompany that with a plan to phase cmake out.</div><div><br></div><div>I very strongly don't think this should happen. cmake does many things right, for example running on all the platforms under the sun and supporting very long-tail issues. By saying "cmake stays the main build system" there's a long list of things we don't need to worry about. If in a few years GN can build on all the platforms under the sun, everything in LLVM works in the GN build, and everyone happens to use it, we could discuss this at that point, but in my opinion this is extremely unlikely to happen. If this is a requirement, I guarantee this thread will fizzle out. Also, I'm very much not interested in pushing for moving llvm off cmake personally.</div><div><br></div><div>> lldb xcode and cmake painful</div><div><br></div><div>I think this is in part because it's tricky to update the xcode build files on non-Apple hardware, and because it's agreed upon which of the two is the canonical one. Here, we very explicitly say that cmake is the official build system that's covered by bots, and your patch has to work there, else it gets reverted. And keeping the gn build up to date is solely the responsibility of people using it.</div><div><br></div><div>This also gives a good metric on if anyone uses the gn build: If they're bitrotted for long stretches, we know it's time to delete them again.</div><div><br></div><div>> I'm curious - would you please outline the problems you've encountered?</div><div><br></div><div>Sure. I did that a bit in <a href="https://reviews.llvm.org/D53944">https://reviews.llvm.org/D53944</a> (the "Intoduction" section) and in my talk. The issues are:</div><div>1. cmake is slow, so it caches things</div><div>2. but cache eviction is hard, so it's very hard to change an existing build dir e.g. from debug to release – for many config values you need to create a completely new build dir to be sure the new values are actually used</div><div>3. gn has support for building the same target with different toolchains in a single build dir, making it e.g. possible to model bootstrap builds or compiler-rt compiles with the built clang much nicer (I haven't implemented that part yet)</div><div><br></div><div>I know I read the following two somewhere but can't find it, so this is an approximate cite:</div><div><br></div><div>> the gn bots should be private, not public</div><div><br></div><div>I agree that no bots on the official LLVM waterfall (<a href="http://lab.llvm.org:8011/console">http://lab.llvm.org:8011/console</a>) should use GN. They would be off-waterfall bots that don't email you and that you wouldn't know about if you didn't go looking for them. They wouldn't even run on LLVM's buildbot instance.</div><div><br></div><div>> so keep them in a separate repo</div><div><br></div><div>Right now, my approach adds the BUILD.gn files in the directory they belong (clang/lib/Support/BUILD.gn, etc). That's not easily possible with a separate repo. Using the secondary tree, this is easier -- but it's still harder than having the files just there, and I don't see which problems are solved by keeping them out of tree.</div><div><br></div><div>>  Most of us don't want to spend their time on build system tasks, right?</div><div><br></div><div>I do like doing them in gn. I find updating gn build files after syncing very relaxing :-) (And I have a script that helps me, so it really isn't much work -- see gn/sync_source_lists_from_cmake.py in my repo) For example, I'm pretty happy with how the setup for how to select which archs to build turned out in the LLVM GN build.</div><div><br></div><div>> Is there a good example where multiple build systems actually coexist well?</div><div><br></div><div>webkit has a bunch, but I wouldn't say that works super well. I'm not aware of any project that has tried experimental, unsupported build systems for enthusiasts in addition to a single main supported build system.</div><div><br></div><div>--</div><div><br></div><div>To reiterate, this is the setup I use for my development. I feel it makes me more happy and productive. Others are interested in it too. I think there's value to be able to experiment in-tree with this since it makes collaboration on the gn files much easier and has zero cost for people not using it. I am not interested in long mailing list discussions about build systems, so I'm very much not interested in proposing to remove cmake. Also, I think requiring that build system experimentation has to have a plan for converging on a single build system again eventually is a basically impossibly high bar.</div></div></div></div></div></div></div></div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr">On Thu, Nov 1, 2018 at 4:44 AM Csaba Raduly <<a href="mailto:rcsaba@gmail.com">rcsaba@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Thu, Nov 1, 2018 at 1:22 AM Vedant Kumar via cfe-dev<br>
<<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:<br>
><br>
> Hi all,<br>
><br>
>> On Oct 31, 2018, at 11:18 AM, Nico Weber via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
>><br>
>> Hi,<br>
>><br>
>> first things first: If you're happy with cmake, you can stop reading now.<br>
>><br>
<br>
I'm not, I just put up with it :)<br>
<br>
> ...<br>
> 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.<br>
><br>
> 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 :)<br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
> best,<br>
> vedant<br>
><br>
><br>
<br>
Precisely. How would the proposed cmake + gn build system be different<br>
from the (deprecated and then removed) autoconf + cmake ?<br>
<br>
Csaba<br>
-- <br>
You can get very substantial performance improvements<br>
by not doing the right thing. - Scott Meyers, An Effective C++11/14 Sampler<br>
So if you're looking for a completely portable, 100% standards-conformat way<br>
to get the wrong information: this is what you want. - Scott Meyers (C++TDaWYK)<br>
</blockquote></div>