[llvm-dev] Contributing Bazel BUILD files similar to gn

[Geoffrey Martin-Noble via llvm-dev]

This seems to have fragmented into a few separate threads, so apologies if
I'm missing someone's response. I don't think I'm going to be able to
effectively reply inline.

The intention here is not to propose Bazel be another community-maintained
build system or that it replace CMake. In my initial message I deliberately
didn't focus on the specific advantages to Bazel because I'm not really
trying to convince anyone to use it. Personally I prefer it to CMake, but
it's got some annoying parts I don't like as well (my project uses both).
The goal here is that if you don't care about Bazel, you should not be
impacted. But some projects (and people) *do* use Bazel and depend on LLVM
and right now that means copying around different versions of these files.
We've been working on at least consolidating these in
https://github.com/google/llvm-bazel. I think Mehdi already summarized the
reasons we think it would make more sense for these to be in-tree than in a
separate repo: it's a more natural collaboration point.

Tom raised some specific concerns about the grounds for adding or removing
a build system and when we know we've got bit rot, pointing out that it can
be harder to tell with a build system if it's not one you actually use! In
this case, we've got a build bot
<https://buildkite.com/llvm-project/bazel-rbe> (lowercase, I'm using
BuildKite) that builds against head every 15 minutes or so (there are
currently some delays caused by pulling in new changes from the monorepo).
Does a functioning bot with a clearly visible (though not noisy!) status
indicator seem like a reasonable requirement? If this bot remains broken
for a long time and/or no one has been updating the build files, then that
would be an indication of bit rot. Someone would send a message to the list
proposing the build files be deleted and doing so should be relatively easy.

I think some of the other general concerns about people using Bazel instead
of CMake and assuming support or breaking the CMake build should be
solvable by Bazel being in a side-directory (as proposed) with a clear
readme that explains the level of support. I'll draft such a readme to
include with the patch (I was waiting to see some responses to the RFC
before doing so).

A side point regarding extra commit traffic. I proposed putting these in
the top-level utils/ directory. Would it also make sense to move gn there
to similarly remove it from commit mailing list traffic?

On Thu, Oct 29, 2020 at 4:11 PM Zachary Turner <zturner at roblox.com> wrote:

>
>
> On Thu, Oct 29, 2020 at 12:49 PM Renato Golin via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> On Thu, 29 Oct 2020 at 19:16, David Blaikie <dblaikie at gmail.com> wrote:
>>
>>> I /believe/ the idea is that, like gn, there are folks maintaining these
>>> build systems out of tree anyway - and having them in tree makes it easier
>>> to coordinate that effort, with the express intent of not burdening the
>>> general community with their upkeep (like gn currently - the idea is that
>>> there's no burden on developers to update gn build files (& consequently
>>> bazel build files)).
>>>
>>
>> Perhaps the initial assumption about my concerns weren't well
>> articulated.
>>
>> I get that those files would be "additional" and other developers won't
>> need to care much about them.
>>
>> But what happens when people join the project with experience in Bazel
>> and, instead of building pure LLVM with CMake, they start using Bazel for
>> everything, just because they're used to it?
>>
>
> Didn't the community already go through this exact discussion when gn was
> added?  Let me ask a different question.  If gn support was permitted, on
> what grounds should we refuse a different parallel build system?  Either we
> should allow people to contribute build systems upstream that they wish to
> maintain, or we should keep every buidl system other than CMake out of the
> tree.
>

I believe that Tom actually highlighted this particular slippery slope as a
concern. Hopefully having some reasonable maintenance standards as
described above can help us avoid it. But I do think we can use gn as an
experiment into how that went. It's been a couple years. Has anyone
experienced issues with their presence in the monorepo?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20201029/a8ce0a9f/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/20201029/a8ce0a9f/attachment.bin>