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

[Mehdi Amini via llvm-dev]

On Thu, Oct 29, 2020 at 12:49 PM Renato Golin <rengolin at gmail.com> 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?
>

I would propose to have the files in a separate tree from llvm/, mlir/,
clang/ ; labelling these clearly as unsupported (either in the path to
these files or in the README, or both), and not provide any public
documentation on llvm.org that would invite users to work with these. The
readme would explain how to use them to include LLVM as a dependency to an
existing Bazel project and document the intent as such.


> Bazel is big enough (at least inside Google) that the probability of that
> happening is not trivial.
>
> What if they create sub-projects that can only build with Bazel? Do we
> refuse inclusion? But don't we have Bazel files already?
>

This is a fair concern: can we defend against this with a clear policy?
Also: no public bot with Bazel or other build system than CMake should help
right?


One big example is Android. They used to build LLVM in a very different
> way, and the inclusion of run-time library files was completely different.
> So different it was not possible to merge some changes they had (128 bit
> maths IIRC) because of the amount of work required.
>
> My point is that adding another build system will not necessarily improve
> the chances of external people contributing to LLVM if they use those build
> systems. It may very well *reduce* those chances.
>

My intuition was that by having the file upstream, we would instead
encourage such users to track the HEAD of our main branch more closely and
so provide them an easier path for upstream work.  The fact that they can
get upstream working with their build environment may provide an incentive
to upstream along the way, even if they have to do the CMake integration
first.
Ultimately while this may facilitate people to go in one direction or
another, I suspect they would just reinforce their natural tendency: people
interested in working more upstream will have a better path, and people who
have less of this tendency may also have an easier path of integration.


Once we get to the point where Bazel support is "complete" enough, and
> enough other projects that use LLVM use Bazel (I assume many internal
> Google projects), the problem I describe above is bound to happen sooner or
> later.
>
> Personally, I'm happy to ignore Bazel and continue using CMake. But I just
> wanted to make clear that in the past, using a different build system did
> not increase the chances of contribution, so that's not a given in this
> case either.
>
> cheers,
> --renato
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20201029/446ad628/attachment.html>