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

[Eric Christopher via llvm-dev]

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>