<div dir="ltr"><div>Hi Renato,</div><div><br></div><div>As a summary: At its core I think that this is a "lowering the barrier to entry" for llvm rather than a support issue. No one is suggesting that this is supported other than by its users inside an easily removed directory similar to how a lot of specific support has been handled.<br><br><div>Your questions are seeming to move the bar far past what anyone is asking for and so it seems that there's a disconnect occurring here. I'll answer a few of your concerns inline.</div><div></div></div><div><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 class="gmail_quote"><div><br></div><div>Tom is worried on a meta level, both as cementing the precedent (GN was a trial, BAZEL makes it official) and as complicating the merge process. I agree with him 100%.</div><div><br></div></div></div></blockquote><div><br></div><div>Makes what official? I think the "support" story - "there is none" - is pretty clear here. As far as merging it's pretty clear this is a "user supported" rather than "community supported" process. No one, including me, wants to add another supported llvm build system. And let's be honest, most people didn't even notice that gn was added until it was pointed out and it hasn't caused any issues. There's no assumption of anything working anywhere.</div><div> </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 class="gmail_quote"><div></div><div>It's already complicated to make sure backports on various projects don't break other projects (especially in the core LLVM), and by adding build systems to the mix, we'd be adding a new dimension in the problem space.</div><div><br></div><div>I am more worried about following different paths for different build systems (non-overlapping features) and encouraging people to build with an "alternative" build system because CMake yet doesn't support something that they do.</div><div><br></div><div>I really don't want to get to a point where each system has a set of unique features, in which case, we'll have three "official" build systems. I know this isn't what you're proposing, but it's a likely outcome once we "support" (core or peripheral) more than one.</div><div><br></div><div>We have had that before with autoconf, as I mentioned. </div><div><br></div></div></div></blockquote><div><br></div><div>There's no notion of having official build systems here and as the previous build system maintainer and owner of autoconf I'm pretty sure this doesn't reflect how the situation was. The dual aspect of cmake and autoconf was an explicit acknowledgment that we wanted to support both in tree while we moved from one to the other. In addition, we still have the vestiges of some other build systems in tree and tools used exclusively for outside projects for simplicity.</div><div> </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 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 class="gmail_quote"><div dir="ltr" class="gmail_attr"><div class="gmail_quote"><div dir="ltr"></div><div class="gmail_quote"><div>I can really only speak for Google projects. I have also noticed several other Bazel build configurations in the wild, e.g. <a href="https://github.com/plaidml/plaidml/blob/master/vendor/llvm/llvm.BUILD" style="background-color:rgb(31,31,31)" target="_blank">PlaidML</a> (Intel) or this <a href="https://github.com/ChrisCummins/bazel_llvm" target="_blank">bazel_llvm</a> project that I found after someone contributed a doc fix. I believe in the last thread someone from Facebook mentioned that Bazel build files would also be relatively easily translatable to their internal Bazel-derived build system, Buck. Someone from Lyft also expressed interest in using a Bazel build configuration if it was in-tree. But I can't really speak to the motivations, road maps, etc. for any of these people, companies, or projects (if you're reading, please chime in ;-P).<br></div></div></div></div></div></div></blockquote><div><br></div><div>The purpose of this question was to understand how many new projects will want to move inside the LLVM umbrella (core, peripheral, incubator) that can only be built with BAZEL.</div><div><br></div></div></div></blockquote><div><br></div><div>This is a different question and one I don't think we need to address, however, if it helps...</div><div><br></div><div>As you say here:</div><div> </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 class="gmail_quote"><div></div><div>If we accept GN/BAZEL as a supported build system, we should still require new projects to build with CMake, in addition to their native ones, if different.<br></div><div><br></div></div></div></blockquote><div><br></div><div>I would be against any project that does not build with CMake being added to the llvm project. If they want to add support (or even support another build system) to one of the optional, and unsupported, build systems then that's up to them or the people that care about those build systems. Same with editor integrations :)</div><div> </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 class="gmail_quote"><div></div><div>This could still "leave out" some features in the native build system (if supported) that haven't been moved to CMake, and that's how you get disjoint support levels I mentioned above.</div><div><br></div></div></div></blockquote><div><br></div><div>As I said in my intro - at its core this isn't a support issue. Adding in the capability of something being able to build with different build systems helps the llvm project both be open to new contributors and integrations. We don't need to support them more than the people care to work on it, but having the capability means that people whose primary goal is integrating llvm into various projects can have those projects' build systems live alongside our supported meta-build system. This is basically "tooling" in a directory that makes integrating with projects that depend upon llvm easier and lowers the barrier for people that work on those projects to more easily work with llvm.</div><div><br></div><div>I hope this helps and would be happy to continue the discussion with you either here, offline, or via video conference.</div><div><br></div><div>Thanks!</div><div><br></div><div>-eric</div><div><br></div><div><br></div><div><br></div></div></div>