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

On Tue, Feb 9, 2021 at 12:46 PM Eric Christopher <echristo at gmail.com>
wrote:
>
>
> On Tue, Feb 9, 2021 at 3:22 PM John Paul Adrian Glaubitz <
> glaubitz at physik.fu-berlin.de> wrote:
>
>> Hi Geoffrey!
>>
>> On 2/9/21 9:09 PM, Geoffrey Martin-Noble via llvm-dev wrote:
>> > The review of "Add Bazel Build Configuration to the LLVM
Monorepo"
>> begins
>> > now and runs through 2021-02-23 (two weeks). The proposal is
available
>> > online
>> > <
>>
https://github.com/llvm/llvm-www/blob/main/proposals/LP0002-BazelBuildConfiguration.md
>> >
>>
>> Bazel currently does not build on any 32-bit architecture and has
issues
>> even
>> on some 64-bit architectures like MIPS or RISC-V:
>>
>> >
>>
https://buildd.debian.org/status/package.php?p=bazel-bootstrap&suite=sid
>>
>> Is there any chance this can get fixed before accepting Bazel support
>> into LLVM?
>>
>>
> Why would this be a limiting factor? It just wouldn't work on those
> platforms?
>
> 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.
> -eric
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20210209/f30d5d21/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/20210209/f30d5d21/attachment.bin>

On Tue, 9 Feb 2021 at 21:00, Geoffrey Martin-Noble <gcmn at google.com>
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.
>
My views exactly. Bazel will not be a "supported" build system and
doesn't
need to build on all platforms and environments LLVM builds. It should only
concern people that actually use Bazel and be completely transparent to the
rest who don't.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20210210/2885d17e/attachment.html>

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.

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.

Adrian
> [1]
https://github.com/bazelbuild/bazel/commit/1c29dff364fd34d7e6158c812cfd6d96f66be747
> [2] https://catfox.life/2021/03/21/really-leaving-the-linux-desktop-behind/
-- 
 .''`.  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