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

(full disclosure, I am a Google employee)

I don't think this is appropriate content, communication, or tone for the
LLVM community.

On Wed, Mar 24, 2021 at 12:39 AM John Paul Adrian Glaubitz via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> On 2/9/21 10:00 PM, Geoffrey Martin-Noble wrote:
> > To expand a bit on Eric's response, the intent here is *not* to
make
> Bazel
> > a supported build system for LLVM or to replace CMake (which I believe
> the
> > proposal makes clear), but rather to enable Bazel usage and shared
> > configuration for people and projects that already use it. I do not
> expect
> > that Bazel will cover all the use cases currently supported by LLVM
CMake
> > any time soon (ever?).I don't work on Bazel itself, so have no
insight on
> > the support plan for those architectures. Only developers interested
in
> > working with Bazel would be expected to use or update the
configuration,
> so
> > lack of support for specific architectures should not affect things, I
> > think.
>
> 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.

> Also, my personal experience with sending patches to Google projects so
> far has been
> rather underwhelming. Usually, Google projects did not accept any patches
> for use
> cases that are not of Google's own interested such as better support
for
> big-endian
> targets [2]. On the other hand, Google engineers expect upstream projects
> to add
> support for technology Google uses internally.
>
> 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.
> [1]
>
https://github.com/bazelbuild/bazel/commit/1c29dff364fd34d7e6158c812cfd6d96f66be747
> [2]
> https://catfox.life/2021/03/21/really-leaving-the-linux-desktop-behind/

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

- Dave
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20210325/b1b257a0/attachment.html>

(full disclosure, I am NOT a Google employee nor I particularly like Bazel)

On Thu, 25 Mar 2021 at 18:12, David Blaikie via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> 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.
>
Exactly! The quality of the build system implementation is entirely
orthogonal to this discussion in particular and to the LLVM community in
general.

The proposal is to have a small sub-community of LLVM use it without any
promise of support. Pretty straightforward.

cheers,
--renato
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20210325/65ef0b05/attachment.html>

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