<div dir="ltr"><div dir="ltr">(full disclosure, I am a Google employee)<br><br>I don't think this is appropriate content, communication, or tone for the LLVM community.<span class="gmail-im" style="color:rgb(80,0,80)"><br><br>On Wed, Mar 24, 2021 at 12:39 AM John Paul Adrian Glaubitz via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br></span></div><div class="gmail_quote"><span class="gmail-im" style="color:rgb(80,0,80)"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 2/9/21 10:00 PM, Geoffrey Martin-Noble wrote:<br>> To expand a bit on Eric's response, the intent here is *not* to make Bazel<br>> a supported build system for LLVM or to replace CMake (which I believe the<br>> proposal makes clear), but rather to enable Bazel usage and shared<br>> configuration for people and projects that already use it. I do not expect<br>> that Bazel will cover all the use cases currently supported by LLVM CMake<br>> any time soon (ever?).I don't work on Bazel itself, so have no insight on<br>> the support plan for those architectures. Only developers interested in<br>> working with Bazel would be expected to use or update the configuration, so<br>> lack of support for specific architectures should not affect things, I<br>> think.<br><br>Looking at the amount of copy-and-paste code in Bazel [1], I'm not really convinced<br>that the code quality of Bazel speaks for itself.<br></blockquote></span><div><br>This patch doesn't seem to me to be reflective of "good" or "bad" code, nor has anyone made any claim about the code quality of Bazel. It isn't relevant to this discussion.<br> </div><span class="gmail-im" style="color:rgb(80,0,80)"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Also, my personal experience with sending patches to Google projects so far has been<br>rather underwhelming. Usually, Google projects did not accept any patches for use<br>cases that are not of Google's own interested such as better support for big-endian<br>targets [2]. On the other hand, Google engineers expect upstream projects to add<br>support for technology Google uses internally.<br><br>I wish it would be more balanced and Google would allow patches in Chromium or V8<br>to support more architectures if - on the other hand - they ask other upstream<br>projects to carry support for their usecases.</blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"></blockquote></span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> [1] <a href="https://github.com/bazelbuild/bazel/commit/1c29dff364fd34d7e6158c812cfd6d96f66be747" rel="noreferrer" target="_blank">https://github.com/bazelbuild/bazel/commit/1c29dff364fd34d7e6158c812cfd6d96f66be747</a></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> [2] <a href="https://catfox.life/2021/03/21/really-leaving-the-linux-desktop-behind/" rel="noreferrer" target="_blank">https://catfox.life/2021/03/21/really-leaving-the-linux-desktop-behind/</a> </blockquote><div><br>These seem like unhelpful ad-hominem criticisms that aren't relevant to the matter being discussed. This proposal has been specifically designed to be minimally impactful to the community (should only be "there are some more commits to the project/more commit list emails" - and if gn is anything to go by, not many (<0.1% I'd wager, at a rough guess)).<br><br>- Dave</div></div></div>