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

Eric Christopher via llvm-dev llvm-dev at lists.llvm.org
Fri Dec 4 21:40:21 PST 2020


On Sat, Dec 5, 2020 at 12:35 AM Stefan Teleman via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> On Sat, Dec 5, 2020 at 12:23 AM Mehdi AMINI <joker.eph at gmail.com> wrote:
> >
> > On Fri, Dec 4, 2020 at 9:06 PM Stefan Teleman via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
> >>
> >> On Fri, Dec 4, 2020 at 11:32 PM Mehdi AMINI via llvm-dev
> >> <llvm-dev at lists.llvm.org> wrote:
> >>
> >> > Another spin to it: the point of working on the policy and putting it
> in place was also to help make sure that such proposals aren't
> automatically controversial to the point where we can't resolve them. If
> the policy does not help us here, that's quite a failure IMO.
> >>
> >> This proposal isn't controversial because of the policy.
> >>
> >> As a matter of historical record, this new policy was shoehorned into
> >> existence ex post facto, after the Bazel build system decision had
> >> already been made, and because some people - myself included -
> >> objected to the proposal. The policy doesn't address the potentially
> >> infinite proliferation of build systems and build system files in
> >> LLVM. Quite the opposite.
> >>
> >> And since you asked: my objections remain the same.  In my opinion,
> >> Bazel build system infrastructure files do not belong in the LLVM tree
> >> anymore than GN, or autoconf, or rpm specs, or Solaris pkg specs do.
> >
> >
> > So you oppose the policy itself, not this particular proposal alone?
> That's fine but that's an important clarification because there is nothing
> this proposal can do to address it, and the point of the policy is to be
> able to consider such proposal without blocking them with such an objection.
>
> No and No.
>
> Q: Do I oppose the policy?
> A: No, I don't. As I have already stated, the policy was created after
> the fact. I am in opposition to the fact. The policy is secondary, and
> irrelevant, because its only purpose is to provide cover for the
> existing fact. If the fact didn't exist, the policy wouldn't be
> necessary.
>
>
I'm sorry, but this is incorrect in every word. The policy encoded existing
practice over the last decade plus and is as we have been implementing all
along. If that doesn't match your experiences as a newer developer I'm
quite sorry, but is the case.

Thanks.

-eric



> Q: Do I not oppose this particular proposal?
> (Warning: bumpy road ahead: double-negation.)
> A: No, I do not not oppose this particular proposal.
> Reduction: Yes, I object to this proposal, just like I objected a
> month and a half ago (or so).
>
> --
> Stefan Teleman
> stefan.teleman at gmail.com
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20201205/d1decd2a/attachment.html>


More information about the llvm-dev mailing list