Krzysztof Parzyszek via llvm-dev
2020-Oct-29 23:56 UTC
[llvm-dev] Contributing Bazel BUILD files similar to gn
On the grounds that it was a bad idea after all. 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<mailto: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<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/f1080e20/attachment.html>
David Blaikie via llvm-dev
2020-Oct-30 01:14 UTC
[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 >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20201029/f7b97b64/attachment.html>
Krzysztof Parzyszek via llvm-dev
2020-Oct-30 13:31 UTC
[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<mailto: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<mailto: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<mailto:kparzysz at quicinc.com> AI tools development 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 6: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. _______________________________________________ LLVM Developers mailing list llvm-dev at lists.llvm.org<mailto: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/09cbacd3/attachment.html>