<div dir="ltr"><div dir="ltr">There be dragons down the path of in-tree N > 1 build systems.</div><div dir="ltr"><br></div><div dir="ltr">Here are just a few:<div>* Compiler bugs that turn out to be differences in how the compiler was built due to differences in the two systems.</div><div>* Build breaks caused by lag-time between synchronization of the N build systems.</div><div>* Development overhead of new features requiring devs to test it in both build configurations or risk build breaks.</div><div>* Maintainer issues for both build systems when devs leave and users report bugs.</div><div><br></div><div>This will inevitably lead to another community effort to deprecate one of the two build systems, similar to what happened in 2013 with autoconf.</div><div><a href="http://llvm.1065342.n5.nabble.com/Deprecating-autoconf-make-td57924.html">http://llvm.1065342.n5.nabble.com/Deprecating-autoconf-make-td57924.html</a><br></div><div><br></div><div>GN is the current build darling of Google. However, on my Red Hat and Ubuntu hosts there are no packages to install and others have pointed out certain architectures aren't supported with GN today. Until gn is a 'dnf install gn' or 'apt install gn' away this makes the build dependencies on LLVM more onerous.<br></div><div><br></div><div>I'm also a bit hesitant because the culture at Google seems to quickly deprecate services and tools for "the-next-new-shiny".  I remember when Chromium and the AOSP used makefiles and moved to GYP. And now GN is replacing GYP in several projects. That's two build system overhauls in the span of about 4 years.</div><div><br></div><div>I would rather have the discussion of the pros/cons of fully replacing CMake and all that would entail for a complex project like LLVM.</div><div><br></div><div><div><div class="gmail_quote"><div dir="ltr">On Thu, Nov 1, 2018 at 11:21 AM John Paul Adrian Glaubitz via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 11/1/18 1:29 AM, Petr Hosek wrote:<br>
> I'm one of GN maintainers, I'd be happy to review to review and<br>
> patches for other systems and architectures. We accepted AIX port a<br>
> few months ago:<br>
> <a href="https://gn.googlesource.com/gn/+/499868c6781dfb87dcefafd8f68dc578f3b70b44" rel="noreferrer" target="_blank">https://gn.googlesource.com/gn/+/499868c6781dfb87dcefafd8f68dc578f3b70b44</a><br>
<br>
Fair enough. I just had the experience with SKIA where my patches were<br>
outright rejected with the answer "We don't care about big-endian".<br>
<br>
This was also the first time I had contact with GN, I wanted to build<br>
SKIA from source on a non-x86 target and eventually gave up after half<br>
an hour or so.<br>
<br>
>> Oh, and btw, any serious Linux distribution would outright reject to package<br>
>> something that involves downloading another chroot to be able to build it,<br>
>> build daemons are - by definition - offline.<br>
> <br>
> We're downloading the sysroot we use to build against to avoid<br>
> dependencies on anything on the bot itself. I agree with you<br>
> completely that this is something that build shouldn't do, and I plan<br>
> on moving that step to the bot script.<br>
<br>
Well, there is no need to tie this into the build system directly, that's<br>
what Travis-CI or Jenkins are for. I'm just getting a bad feeling in my<br>
stomach if the solution for building a tool from source is to download<br>
a complete build environment instead of using tools on the target system<br>
to achieve that.<br>
<br>
> Until a few months ago, GN was part of Chromium and was relying on its<br>
> infrastructure, build and source. We've decided to split GN into a<br>
> separate project because it's being adopted by other projects and<br>
> users outside of Chromium. We're still dealing with fallout of that<br>
> separation and resulting cleanup. I hope that eventually building GN<br>
> will be as simple and easy as Ninja itself.<br>
<br>
Ok, then I hope that LLVM will be buildable with cmake until GN is<br>
mature enough that I can build it from source on any architecture<br>
on Linux without me jumping through loops.<br>
<br>
Thanks,<br>
Adrian<br>
<br>
-- <br>
 .''`.  John Paul Adrian Glaubitz<br>
: :' :  Debian Developer - <a href="mailto:glaubitz@debian.org" target="_blank">glaubitz@debian.org</a><br>
`. `'   Freie Universitaet Berlin - <a href="mailto:glaubitz@physik.fu-berlin.de" target="_blank">glaubitz@physik.fu-berlin.de</a><br>
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913<br>
<br>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
</blockquote></div></div></div></div></div>