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

[Renato Golin via llvm-dev]

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?

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?

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.

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/152841f5/attachment.html>