<div dir="ltr"><div>Hi John,</div><div><br></div><div>All of these concerns were brought up and addressed in the review. We have decided to move forward.</div><div><br></div><div>Thanks.</div><div><br></div><div>-eric</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Mar 25, 2021 at 4:10 PM John Paul Adrian Glaubitz <<a href="mailto:glaubitz@physik.fu-berlin.de">glaubitz@physik.fu-berlin.de</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">Hello David!<br>
<br>
On 3/25/21 7:12 PM, David Blaikie wrote:<br>
> (full disclosure, I am a Google employee)<br>
> <br>
> I don't think this is appropriate content, communication, or tone for the<br>
> LLVM community.<br>
<br>
Since English is not my native language, my wording may not convey 100% what I'm<br>
trying to say and my tone may seem inappropriate. However, is not my intention to<br>
be rude, I'm just trying to raise some concerns given the current state of Bazel<br>
and the personal experiences I made with some Google projects in the past.<br>
<br>
>> Looking at the amount of copy-and-paste code in Bazel [1], I'm not really<br>
>> convinced<br>
>> that the code quality of Bazel speaks for itself.<br>
>><br>
> <br>
> This patch doesn't seem to me to be reflective of "good" or "bad" code, nor<br>
> has anyone made any claim about the code quality of Bazel. It isn't<br>
> relevant to this discussion.<br>
<br>
My personal concern is that Bazel will eventually have an impact on the portability<br>
of LLVM or any other projects that adopt it like Chromium did in the past with project<br>
adopting it as their HTML rendering engine. Looking at the current build status of Bazel<br>
in Debian, it builds on 6 of the 23 architecture/platform combinations that Debian<br>
supports,<br>
<br>
> <a href="https://buildd.debian.org/status/package.php?p=bazel-bootstrap&suite=sid" rel="noreferrer" target="_blank">https://buildd.debian.org/status/package.php?p=bazel-bootstrap&suite=sid</a><br>
<br>
which I find rather suboptimal for a build system. The build system should not be<br>
the limiting factor when it comes to portability and I know no other build system<br>
besides "gn" which has similar portability issues. cmake, meson, scons, qmake and<br>
so on don't have these portability limitations. They just work on any target you<br>
compile them for and they can also easily be bootstrapped.<br>
<br>
For "gn", I needed to download a prebuilt build-enviroment (IIRC a whole chroot) to<br>
build it from source back then. I don't know if that has changed in the meantime.<br>
<br>
>> I wish it would be more balanced and Google would allow patches in<br>
>> Chromium or V8<br>
>> to support more architectures if - on the other hand - they ask other<br>
>> upstream<br>
>> projects to carry support for their usecases.<br>
> <br>
> These seem like unhelpful ad-hominem criticisms that aren't relevant to the<br>
> matter being discussed. This proposal has been specifically designed to be<br>
> minimally impactful to the community (should only be "there are some more<br>
> commits to the project/more commit list emails" - and if gn is anything to<br>
> go by, not many (<0.1% I'd wager, at a rough guess)).<br>
<br>
I don't think that stating facts are ad-hominem attacks. I made similar experiences<br>
with Google projects and I found these experiences frustrating. In particular, one<br>
of the experiences was an endianness issue with Skia [1] which has also seen wider<br>
adoption in other projects which means missing portability hurts the portability of<br>
these projects. There was also a SPARC port for Go which got rejected due to lack of<br>
interest by the upstream project and the POWER port of Chromium [2] which got never<br>
merged for whatever reason. As a result, any project that adopts any of these technologies<br>
will reduce its portability.<br>
<br>
KMail, KDE's email client, for example used to be highly portable and was available<br>
of all of Debian's supported architectures/platforms. Nowadays, KMail just runs<br>
on the few architectures that Chromium supports which I consider a step backwards.<br>
<br>
So I personally would like to see that Bazel becomes as portable as any other commonly<br>
used build system before it is advertised as a versatile and advanced build system so<br>
that it's not going to have the same impacts on portability as Chromium does.<br>
<br>
Adrian<br>
<br>
> [1] <a href="https://bugs.chromium.org/p/skia/issues/detail?id=7808" rel="noreferrer" target="_blank">https://bugs.chromium.org/p/skia/issues/detail?id=7808</a><br>
> [2] <a href="https://groups.google.com/a/chromium.org/g/chromium-dev/c/MYq1DPz9Tak" rel="noreferrer" target="_blank">https://groups.google.com/a/chromium.org/g/chromium-dev/c/MYq1DPz9Tak</a><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>
</blockquote></div></div>