[llvm-dev] [PROPOSAL] Add Bazel Build Configuration to the LLVM Monorepo

[John Paul Adrian Glaubitz via llvm-dev]

Hello David!

On 3/25/21 7:12 PM, David Blaikie wrote:
> (full disclosure, I am a Google employee)
> 
> I don't think this is appropriate content, communication, or tone for the
> LLVM community.

Since English is not my native language, my wording may not convey 100% what I'm
trying to say and my tone may seem inappropriate. However, is not my intention to
be rude, I'm just trying to raise some concerns given the current state of Bazel
and the personal experiences I made with some Google projects in the past.

>> Looking at the amount of copy-and-paste code in Bazel [1], I'm not really
>> convinced
>> that the code quality of Bazel speaks for itself.
>>
> 
> 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.

My personal concern is that Bazel will eventually have an impact on the portability
of LLVM or any other projects that adopt it like Chromium did in the past with project
adopting it as their HTML rendering engine. Looking at the current build status of Bazel
in Debian, it builds on 6 of the 23 architecture/platform combinations that Debian
supports,

> https://buildd.debian.org/status/package.php?p=bazel-bootstrap&suite=sid

which I find rather suboptimal for a build system. The build system should not be
the limiting factor when it comes to portability and I know no other build system
besides "gn" which has similar portability issues. cmake, meson, scons, qmake and
so on don't have these portability limitations. They just work on any target you
compile them for and they can also easily be bootstrapped.

For "gn", I needed to download a prebuilt build-enviroment (IIRC a whole chroot) to
build it from source back then. I don't know if that has changed in the meantime.

>> I wish it would be more balanced and Google would allow patches in
>> Chromium or V8
>> to support more architectures if - on the other hand - they ask other
>> upstream
>> projects to carry support for their usecases.
> 
> 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)).

I don't think that stating facts are ad-hominem attacks. I made similar experiences
with Google projects and I found these experiences frustrating. In particular, one
of the experiences was an endianness issue with Skia [1] which has also seen wider
adoption in other projects which means missing portability hurts the portability of
these projects. There was also a SPARC port for Go which got rejected due to lack of
interest by the upstream project and the POWER port of Chromium [2] which got never
merged for whatever reason. As a result, any project that adopts any of these technologies
will reduce its portability.

KMail, KDE's email client, for example used to be highly portable and was available
of all of Debian's supported architectures/platforms. Nowadays, KMail just runs
on the few architectures that Chromium supports which I consider a step backwards.

So I personally would like to see that Bazel becomes as portable as any other commonly
used build system before it is advertised as a versatile and advanced build system so
that it's not going to have the same impacts on portability as Chromium does.

Adrian

> [1] https://bugs.chromium.org/p/skia/issues/detail?id=7808
> [2] https://groups.google.com/a/chromium.org/g/chromium-dev/c/MYq1DPz9Tak

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz at debian.org
`. `'   Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913