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

[Chris Tetreault via llvm-dev]

Renato,

   I feel that adding the support policy was useful. The policy documents expectations, and consequences for non-compliance. This eliminates a whole class of objections that, for the most part, are no longer being made. Honestly, I feel like the support policy settled most of the technical arguments. It requires that the Bazel build files be supported, that they not impact the rest of the codebase, and documents at what point they will be removed. I suppose it should go without saying that they should be high quality. All that remains is semantics, history, and precedence.

llvm-dev,

   As for escalating to the LLVM proposal process, it seems to me that we have reached an impasse. Stefan seems to be strongly opposed, and as far as I can tell, so are you. I’m not in love with the plan either, though I am prepared to accept any outcome of this RFC at this point. I think Stefan’s objection is valid. Just because we have a policy that enumerates the basic requirements for some non-essential thing to be added, and lists conditions for removal, does not mean that all things that meet the basic requirements should be added. I mean, if “because it meets the basic criteria per the support policy” is enough, then I might as well add an MSBuild project because the one CMake generates isn’t ideal. I’m sure the MS folks that work with LLVM wouldn’t mind a hand-rolled MSBuild project being in tree. I’m sure Apple would like their hand-rolled XCode project back. Maybe the GHC folks want a Shake based build system? There needs to be limits.

   As a side note, maybe listing Bazel as an example wasn’t a great idea. I guess if we end up accepting the Bazel build files, then it’s fine. But if it gets rejected, a patch should probably be submitted to remove it as an example from line 100 of SupportPolicy.rst.

Thanks,
   Christopher Tetreault

From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of Renato Golin via llvm-dev
Sent: Sunday, December 6, 2020 4:08 AM
To: Mehdi AMINI <joker.eph at gmail.com>
Cc: LLVM Dev <llvm-dev at lists.llvm.org>
Subject: Re: [llvm-dev] RFC: Contributing Bazel BUILD files in the "peripheral" support tier

On Sun, 6 Dec 2020 at 04:38, Mehdi AMINI <joker.eph at gmail.com<mailto: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/20201207/747d903b/attachment.html>