<div dir="ltr"><div dir="ltr">This seems to have fragmented into a few separate threads, so apologies if I'm missing someone's response. I don't think I'm going to be able to effectively reply inline.<div><br></div><div>The intention here is not to propose Bazel be another community-maintained build system or that it replace CMake. In my initial message I deliberately didn't focus on the specific advantages to Bazel because I'm not really trying to convince anyone to use it. Personally I prefer it to CMake, but it's got some annoying parts I don't like as well (my project uses both). The goal here is that if you don't care about Bazel, you should not be impacted. But some projects (and people) *do* use Bazel and depend on LLVM and right now that means copying around different versions of these files. We've been working on at least consolidating these in <a href="https://github.com/google/llvm-bazel" target="_blank" class="cremed">https://github.com/google/llvm-bazel</a>. I think Mehdi already summarized the reasons we think it would make more sense for these to be in-tree than in a separate repo: it's a more natural collaboration point.</div><div><br></div><div>Tom raised some specific concerns about the grounds for adding or removing a build system and when we know we've got bit rot, pointing out that it can be harder to tell with a build system if it's not one you actually use! In this case, we've got a <a href="https://buildkite.com/llvm-project/bazel-rbe" target="_blank" class="cremed">build bot</a> (lowercase, I'm using BuildKite) that builds against head every 15 minutes or so (there are currently some delays caused by pulling in new changes from the monorepo). Does a functioning bot with a clearly visible (though not noisy!) status indicator seem like a reasonable requirement? If this bot remains broken for a long time and/or no one has been updating the build files, then that would be an indication of bit rot. Someone would send a message to the list proposing the build files be deleted and doing so should be relatively easy.<br></div><div><br></div><div>I think some of the other general concerns about people using Bazel instead of CMake and assuming support or breaking the CMake build should be solvable by Bazel being in a side-directory (as proposed) with a clear readme that explains the level of support. I'll draft such a readme to include with the patch (I was waiting to see some responses to the RFC before doing so).</div><div></div></div><div><br></div><div>A side point regarding extra commit traffic. I proposed putting these in the top-level utils/ directory. Would it also make sense to move gn there to similarly remove it from commit mailing list traffic?</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Oct 29, 2020 at 4:11 PM Zachary Turner <<a href="mailto:zturner@roblox.com" target="_blank" class="cremed">zturner@roblox.com</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"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Oct 29, 2020 at 12:49 PM Renato Golin via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="cremed">llvm-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"><div dir="ltr"><div dir="ltr">On Thu, 29 Oct 2020 at 19:16, David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank" class="cremed">dblaikie@gmail.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">I /believe/ the idea is that, like gn, there are folks maintaining these build systems out of tree anyway - and having them in tree makes it easier to coordinate that effort, with the express intent of not burdening the general community with their upkeep (like gn currently - the idea is that there's no burden on developers to update gn build files (& consequently bazel build files)).<br></div></div></blockquote><div><br></div><div>Perhaps the initial assumption about my concerns weren't well articulated. </div><div><br></div><div>I get that those files would be "additional" and other developers won't need to care much about them. </div><div><br></div><div>But what happens when people join the project with experience in Bazel and, instead of building pure LLVM with CMake, they start using Bazel for everything, just because they're used to it?</div></div></div></blockquote><div><br></div><div>Didn't the community already go through this exact discussion when gn was added?  Let me ask a different question.  If gn support was permitted, on what grounds should we refuse a different parallel build system?  Either we should allow people to contribute build systems upstream that they wish to maintain, or we should keep every buidl system other than CMake out of the tree. </div></div></div></blockquote><div><br></div><div>I believe that Tom actually highlighted this particular slippery slope as a concern. Hopefully having some reasonable maintenance standards as described above can help us avoid it. But I do think we can use gn as an experiment into how that went. It's been a couple years. Has anyone experienced issues with their presence in the monorepo?</div></div></div>