[llvm-dev] RFC: Contributing Bazel BUILD files in the "peripheral" support tier

Renato Golin via llvm-dev llvm-dev at lists.llvm.org
Tue Nov 17 02:26:58 PST 2020


Hi Geoffrey,

Thanks for the re-submission.

I have some comments below that may sound negative, but they're probably
just a reflection of my own ignorance. I want to make sure the submission
is clear, so it can be accepted on its own right.

On Tue, 17 Nov 2020 at 03:02, Geoffrey Martin-Noble via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

>  This should not affect development of core tier components. One reason we
> propose adding this to the root utils/ directory instead of under
> llvm/utils (where GN is located) is to avoid unnecessarily sending messages
> to llvm-commits. Others have raised the concern that the existence of an
> alternative build system might lead to lack of maintenance for the CMake
> build system. Given that supporting CMake will remain a requirement and
> maintenance of a Bazel build system will continue to happen regardless, we
> do not expect any significant impact in this way.
>

I was under the impression that "utils" was actually "llvm/utils", which
would be in the same place as GN. I don't think we should treat GN and
Bazel as different and I really wouldn't like to have a different quality
control (for post commit reviews).

If the Bazel commits are too verbose (for example, committing
auto-generated code), then we should really clean that up and commit the
script that generates them and make that part of the build.

I understand the need to move the noise away, but move it too far away and
it's no better than in a separate repo.

A number of people raised the question of "why not a separate repository".
> This is indeed possible: It's what we've done with
> https://github.com/google/llvm-bazel, which is currently used by
> https://github.com/google/iree. It is significantly more infrastructure,
> coordination, and complexity for something that is specifically a
> configuration for the LLVM project itself, not its own dependent or
> adjacent project.
>

I was also under the impression that one of the big reasons why we needed
it to be in LLVM is that, like CMake, it needed files all over the place.
This would indeed be a major infrastructure undertaking.

But given that it's all being hosted in a single directory, and outside of
the LLVM tree, I really can't see what's so much harder about an extra
checkout in the same tree.

I believe this contribution will significantly improve the situation for
> downstream users that use Bazel while having minimal impact on the
> community at large.
>

It's not clear to me yet if LLVM/Bazel is only used in Google projects or
any other non-Google project. All that you listed so far seem to be
exclusive to Google.

This is not a problem per se, but it does promote the idea that Google
could common it up internally instead.

The main reasons why it would be upstream are that it's either a product by
or requirement to the project itself, or it helps unite cross-industry
collaboration that wouldn't be possible otherwise.

It's clearly not the former (and why it's in the periphery tier), but it's
also not clear it's in the latter either.

cheers,
--renato
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20201117/614bfa33/attachment.html>


More information about the llvm-dev mailing list