<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Wed, Oct 31, 2018 at 4:24 PM Petr Hosek via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I'll volunteer to maintain the GN files if the community is in favor<br>
of having those in the tree.</blockquote><div>... </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">GN has a first-class concept of a toolchain and it allows<br>
"applying" these toolchains on dependencies, so you can express the<br>
fact that a particular dependency should be built with a different<br>
toolchain, which could be a completely different compiler or just a<br>
different set of flags. This is an extremely powerful concept that<br>
would be useful for things like runtimes build.<br></blockquote><div><br></div><div>I think your use case and Nico's are a bit different. In the fullness of time, I expect that you will show that gn's toolchain support works really well, and more people will want to use it for similar reasons. Eventually, consensus will grow that it should be an officially supported build system. I don't doubt that you are volunteering to maintain it yourself for now, but I want to acknowledge that there is a very real possibility of scope creep. If runtimes are in scope for this, then that really means the gn files are going to be a full second build system with support for making a real toolchain package. At some point, we may wind up with a second system just as complicated as cmake, although it'll be much faster.</div><div><br></div><div>After writing the paragraph above, I realized that one of the big costs of cmake is iteration time. If you want to fix a build system problem today, you have to run cmake as part of your inner development loop. This incentivizes people to avoid touching the build system if at all possible, and it fills up with little quick fixes that nobody wants to refactor. If we were using gn, I would be much happier iterating on changes to the build system, since I would be able to test small incremental changes quickly.</div><div><br></div><div>I guess my opinion is, LLVM is big enough to have a second build system in tree, with all the costs that that implies. gn is really the only new build system that I'm actually excited about, so if we're going to have a second one, it should be this one. </div></div></div>