[llvm-dev] Contributing Bazel BUILD files similar to gn

Fri Oct 30 08:21:50 PDT 2020

Yes? We have in the past and I and others have fixed them.

-eric

On Fri, Oct 30, 2020 at 10:06 AM Krzysztof Parzyszek via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> The question to ask may be: if they happened to be broken, would we, as
> the project community, accept bug reports about them?
>
>
>
> --
>
> Krzysztof Parzyszek  kparzysz at quicinc.com   AI tools development
>
>
>
> *From:* Keane, Erich <erich.keane at intel.com>
> *Sent:* Friday, October 30, 2020 8:49 AM
> *To:* Krzysztof Parzyszek <kparzysz at quicinc.com>; David Blaikie <
> dblaikie at gmail.com>; llvm-dev <llvm-dev at lists.llvm.org>
> *Subject:* [EXT] RE: [llvm-dev] Contributing Bazel BUILD files similar to
> gn
>
>
>
> As far as prior-art here, don’t we have a bunch of MSVC and GDB debug
> ‘pretty print scripts’ in the repo as well?  Both of those are not
> particularly well maintained and only serve the handful of people who
> maintain them.
>
>
>
> *From:* llvm-dev <llvm-dev-bounces at lists.llvm.org> *On Behalf Of *Krzysztof
> Parzyszek via llvm-dev
> *Sent:* Friday, October 30, 2020 6:31 AM
> *To:* David Blaikie <dblaikie at gmail.com>
> *Cc:* llvm-dev at lists.llvm.org
> *Subject:* Re: [llvm-dev] Contributing Bazel BUILD files similar to gn
>
>
>
> It’s not a practical experience that makes me think it was a bad idea.
> It’s the principle that there are files in the project repository that the
> community is not responsible for.  When a new target is added to the
> project, we all assume some degree of responsibility for it, even if we
> never use it.  This is not the case for the alternative build systems.  For
> those, we are simply renting out storage space in our repo, so to speak.
> Any tangible consequences may take time to appear, but by then they may be
> difficult to deal with.
>
>
>
> Finally, the question shouldn’t be whether it’s causing ongoing
> difficulties, but whether we want to make it a part of the project.
>
>
>
>
>
>
>
> --
>
> Krzysztof Parzyszek  kparzysz at quicinc.com   AI tools development
>
>
>
> *From:* David Blaikie <dblaikie at gmail.com>
> *Sent:* Thursday, October 29, 2020 8:14 PM
> *To:* Krzysztof Parzyszek <kparzysz at quicinc.com>
> *Cc:* llvm-dev at lists.llvm.org
> *Subject:* [EXT] Re: [llvm-dev] Contributing Bazel BUILD files similar to
> gn
>
>
>
>
>
>
>
> On Thu, Oct 29, 2020 at 4:57 PM Krzysztof Parzyszek via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
> On the grounds that it was a bad idea after all.
>
>
> Could you clarify this a bit further? Are there particular outcomes of
> that decision now that we've got some practical experience with it for a
> while now that was unanticipated in the original proposal/acceptance? What
> sort of ongoing costs/pain do you find the gn build system is causing the
> LLVM project?
>
>
>
>
> Any commits going into the LLVM repository should not break any part of
> it, at least not without a consideration for a fix.  There is an exception
> to it---experimental targets.  They can be broken, but they are there with
> the explicit intent of becoming officially supported.
>
>
>
> Same thing applies to the cmake files.  If they get broken, they need to
> be fixed, but the same doesn’t apply to the extraneous build systems.  They
> can be broken and never fixed.  There is no commitment from the community
> as a whole to keep them working.  IMO, this isn’t right, and files like
> that should not be a part of the official repository.
>
>
>
> Whether GN or Bazel have superior features is irrelevant.  Unless their
> configuration files are a part of a longer-term transition process, they
> don’t belong in the repo.
>
>
>
>
>
> --
>
> Krzysztof Parzyszek  kparzysz at quicinc.com   AI tools development
>
>
>
> *From:* llvm-dev <llvm-dev-bounces at lists.llvm.org> *On Behalf Of *Zachary
> Turner via llvm-dev
> *Sent:* Thursday, October 29, 2020 6: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
>
> _______________________________________________
> 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/20201030/bdd74781/attachment.html>