llvm dev - Oct 2020 - Contributing Bazel BUILD files similar to gn

I think this argument is the slippery slope in action. Just because we allowed
the gn build system to be added previously, does not mean that we should allow a
new build system now. And forbidding this build system now does not mean that we
must kick gn out of the repo.

We should accept or reject Bazel on its merits alone, and not based on
historical precedent.

From: llvm-dev <llvm-dev-bounces at lists.llvm.org<mailto:llvm-dev-bounces
at lists.llvm.org>> On Behalf Of Zachary Turner via llvm-dev
Sent: Thursday, October 29, 2020 4:11 PM
To: Renato Golin <rengolin at gmail.com<mailto:rengolin at
gmail.com>>
Cc: Mehdi Amini <aminim at google.com<mailto:aminim at google.com>>;
LLVM Dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at
lists.llvm.org>>; Stella Laurenzo <laurenzo at
google.com<mailto:laurenzo at google.com>>; Tres Popp <tpopp at
google.com<mailto:tpopp at google.com>>; Geoffrey Martin-Noble <gcmn
at google.com<mailto:gcmn at google.com>>; Thomas Joerg <tjoerg at
google.com<mailto:tjoerg at google.com>>
Subject: [EXT] Re: [llvm-dev] Contributing Bazel BUILD files similar to gn



On Thu, Oct 29, 2020 at 12:49 PM Renato Golin via llvm-dev <llvm-dev at
lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote:
On Thu, 29 Oct 2020 at 19:16, David Blaikie <dblaikie at
gmail.com<mailto:dblaikie at gmail.com>> wrote:
I /believe/ the idea is that, like gn, there are folks maintaining these build
systems out of tree anyway - and having them in tree makes it easier to
coordinate that effort, with the express intent of not burdening the general
community with their upkeep (like gn currently - the idea is that there's no
burden on developers to update gn build files (& consequently bazel build
files)).

Perhaps the initial assumption about my concerns weren't well articulated.

I get that those files would be "additional" and other developers
won't need to care much about them.

But what happens when people join the project with experience in Bazel and,
instead of building pure LLVM with CMake, they start using Bazel for everything,
just because they're used to it?

Didn't the community already go through this exact discussion when gn was
added?  Let me ask a different question.  If gn support was permitted, on what
grounds should we refuse a different parallel build system?  Either we should
allow people to contribute build systems upstream that they wish to maintain, or
we should keep every buidl system other than CMake out of the tree.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20201029/9ea26a40/attachment-0001.html>

On Thu, Oct 29, 2020 at 4:50 PM Chris Tetreault via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

(side note: Chris: There's /something/ about your emails that isn't
threading in gmail at least - not sure if it's something you're aware
of/something you can do anything about, but figured I'd mention (hmm, looks
like they thread correctly on the llvm-dev archive, so the headers are
probably correct - the subject lines look the same, so I really don't know
what gmail's doing with them))

I think this argument is the slippery slope in action. Just because
we
> allowed the gn build system to be added previously, does not mean that we
> should allow a new build system now. And forbidding this build system now
> does not mean that we must kick gn out of the repo.
>
>
>
> We should accept or reject Bazel on its merits alone, and not based on
> historical precedent.
>
I don't entirely agree - I think it's worth asking whether there's
significant differences between this and previous choices. Precedent has
bearing to me - "slippery slope" is a fallacy that if we allow A we
must
allow B, specifically when B does not follow from A. That we allow gn
doesn't necessarily mean we have to allow all build systems, or that we
have to allow Bazel - they are different, but are they different in
significant ways that matter I think is the question.

I think relevant questions to ask to avoid rehashing the same decisions
would be:

What problems do you/we find with the gn integration, that we could learn
from to avoid making similar mistakes?
Have there been problems/costs to the community with the gn integration
that we'd like to avoid incurring more of?
Otherwise, are there things that make Bazel integration different from gn
that might make it worse/different in terms of costs to the community?

>
>
> *From:* llvm-dev <llvm-dev-bounces at lists.llvm.org> *On Behalf Of
*Zachary
> Turner via llvm-dev
> *Sent:* Thursday, October 29, 2020 4:11 PM
> *To:* Renato Golin <rengolin at gmail.com>
> *Cc:* Mehdi Amini <aminim at google.com>; LLVM Dev <llvm-dev at
lists.llvm.org>;
> Stella Laurenzo <laurenzo at google.com>; Tres Popp <tpopp at
google.com>;
> Geoffrey Martin-Noble <gcmn at google.com>; Thomas Joerg <tjoerg
at google.com>
> *Subject:* [EXT] Re: [llvm-dev] Contributing Bazel BUILD files similar to
> gn
>
>
>
>
>
>
>
> On Thu, Oct 29, 2020 at 12:49 PM Renato Golin via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
> On Thu, 29 Oct 2020 at 19:16, David Blaikie <dblaikie at gmail.com>
wrote:
>
> I /believe/ the idea is that, like gn, there are folks maintaining these
> build systems out of tree anyway - and having them in tree makes it easier
> to coordinate that effort, with the express intent of not burdening the
> general community with their upkeep (like gn currently - the idea is that
> there's no burden on developers to update gn build files (&
consequently
> bazel build files)).
>
>
>
> Perhaps the initial assumption about my concerns weren't well
articulated.
>
>
>
> I get that those files would be "additional" and other developers
won't
> need to care much about them.
>
>
>
> But what happens when people join the project with experience in Bazel
> and, instead of building pure LLVM with CMake, they start using Bazel for
> everything, just because they're used to it?
>
>
>
> Didn't the community already go through this exact discussion when gn
was
> added?  Let me ask a different question.  If gn support was permitted, on
> what grounds should we refuse a different parallel build system?  Either we
> should allow people to contribute build systems upstream that they wish to
> maintain, or we should keep every buidl system other than CMake out of the
> tree.
> _______________________________________________
> 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/20201029/f8f20c92/attachment.html>