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

Geoffrey Martin-Noble via llvm-dev llvm-dev at lists.llvm.org
Wed Jun 16 22:43:56 PDT 2021


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

On Wed, Jun 16, 2021, 22:39 David Blaikie <dblaikie at gmail.com> wrote:

> 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/468b2aab/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3992 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210616/468b2aab/attachment.bin>


More information about the llvm-dev mailing list