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

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

Hi John,

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

Thanks.

-eric

On Thu, Mar 25, 2021 at 4:10 PM John Paul Adrian Glaubitz <
glaubitz at physik.fu-berlin.de> wrote:
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20210325/425478b4/attachment.html>

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,

-Chris
> On Mar 25, 2021, at 1:10 PM, John Paul Adrian Glaubitz via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> 
> 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
> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev