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

Wed Jun 16 22:39:30 PDT 2021

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)

On Wed, Jun 16, 2021 at 11:14 AM Geoffrey Martin-Noble via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> 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?
>
> On Thu, Mar 25, 2021 at 6:33 PM Chris Lattner via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> 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
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210616/a0086ea9/attachment.html>