[PROPOSAL] Add Bazel Build Configuration to the LLVM Monorepo

Hello David!

(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
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


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
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.


Hi John,

All of these concerns were brought up and addressed in the review. We have decided to move forward.



Hi Adrian,

This proposal is not changing the LLVM build system. We are sticking with cmake. This is just checking in some extra files into the repository to help out a sub community that cares about bazel. As others mentioned, this was discussed in depth in the proposal and related threads,


I’d like to follow up here because the patch to introduce these files has been updated and available for review for some time now (about 3 weeks) without reviewer attention. Could interested parties please take a look?

Might be good to include a link to the review. (at a glance I don’t see a link to it in your email here)

Ah you’re quite right, thanks David. The patch is at https://reviews.llvm.org/D90352