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

Renato Golin via llvm-dev llvm-dev at lists.llvm.org
Thu Oct 29 14:15:56 PDT 2020


On Thu, 29 Oct 2020 at 20:46, Mehdi Amini <aminim at google.com> wrote:

> 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.
>

Sounds good, with the addendum below:

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?
>

Right, as you said later, no emails from broken bots, ie. people that use
non-CMake build systems are expected to fix their own builds, even if the
breakage came from a third-party change.

Of course, we expect other contributors to help with what they can, but
it's not their responsibility. Such is the cost of having a different build
system.

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.
>

The benefit to keep the files in LLVM is clear to all Bazel users out
there. I don't think that's a problem for the rest of LLVM.

My point was that the reason why Arm's patch (128-bit) was
"uncontributable" was because their build system was so different, it was
impossible to keep both versions on their merged tree. This is a big
problem to the Bazel users, not CMake users.

If we keep the policy of "not my problem", I don't see a single problem to
CMake users. But that's slightly unfriendly to people that came later to
LLVM and "didn't know better" before creating a whole project in Bazel, etc.

I'm strictly not thinking about myself here.

--renato

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20201029/396b731b/attachment.html>


More information about the llvm-dev mailing list