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

[Renato Golin via llvm-dev]

On Sun, 6 Dec 2020 at 04:38, Mehdi AMINI <joker.eph at gmail.com> wrote:

> It isn't clear to me what makes you say that? You may not have been
> involved with it and you may haven't been paying attention at the time, but
> it seems unfair to claim that it didn't have scrutiny or it went in without
> the usual proper consideration.
> In particular it has been discussed on llvm-dev@ like any other proposal,
> and the thread was pretty long:
> http://lists.llvm.org/pipermail/llvm-dev/2018-October/127342.html ; it
> also went further with a lightning talk **and** a round-table during a llvm
> dev meeting.
>

Sorry, scrutiny was the wrong word. I meant "trouble". This proposal seems
to be having a lot of trouble that GN should have had too. The biggest push
back is about adding new build systems, not Bazel versus GN versus CMake.

There seems to be a conflict here about adding a secondary build system.
The first could be always thought of as an exception, but the second looks
very much like a pattern. The way I see it, from one side there's people
worried about maintenance and proliferation of code that is not directly
related to the LLVM project (like build systems, editor files, etc) and
from the other side, there's people saying this has been happening for a
long time.

I tried to solve that by starting the support policy, but not with the
intent to validate the inclusion of GN/Bazel, just to help the discussion
move to a consensus. I regret having written GN and Bazel by name, which
only now I realise they could be used as leverage for one side of the
discussion. It was not my intention, and I don't think we should ignore the
issues just because GN has been included already, either.

My support for moving this to a document (not necessarily a proposal) is
because for most of the original discussion around Bazel, throughout the
discussion about the support policy and now the retake on Bazel's
inclusions, Tom's points haven't been addressed completely. There seems to
be more discussion around semantics, history and precedence than the actual
technical details. I'm guilty of that, too, while trying to solve the
conflict, and I apologise if the support policy has created more confusion
than it solved.

I think laying out the issues in a document and discussing the technical
aspects over it would make things easier, not harder. If the support policy
needs to be amended to clarify that, so be it. We need to document what
happens and what we want to happen, not fix some version of the past as a
golden standard for the future.

But as I always say: whatever works. If you want to continue discussing in
this thread, by all means, do go on.

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