<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Dec 4, 2020 at 8:56 PM Tom Stellard <<a href="mailto:tstellar@redhat.com">tstellar@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">On 12/4/20 8:17 PM, Mehdi AMINI wrote:<br>
> <br>
> <br>
> On Fri, Dec 4, 2020 at 8:07 PM Tom Stellard <<a href="mailto:tstellar@redhat.com" target="_blank">tstellar@redhat.com</a> <br>
> <mailto:<a href="mailto:tstellar@redhat.com" target="_blank">tstellar@redhat.com</a>>> wrote:<br>
> <br>
> On 12/4/20 7:19 PM, Mehdi AMINI wrote:<br>
> ><br>
> ><br>
> > On Fri, Dec 4, 2020 at 6:42 PM Tom Stellard via llvm-dev<br>
> > <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a> <mailto:<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>><br>
> <mailto:<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a> <mailto:<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>>>><br>
> wrote:<br>
> ><br>
> > On 12/3/20 4:27 PM, Geoffrey Martin-Noble wrote:<br>
> > > Apologies for the delayed response here. I was out of the<br>
> "office".<br>
> > ><br>
> > > Thanks for taking another look :-)<br>
> > ><br>
> > > I want to respond first to the process question of pitch<br>
> vs RFC. My<br>
> > > impression was that the pitch process should be used in<br>
> the case<br>
> > that an<br>
> > > RFC couldn't reach consensus. I asked a few times in the<br>
> last thread<br>
> > ><br>
> > <br>
> (<a href="https://groups.google.com/g/llvm-dev/c/u07o3QREVUg/m/uVlV3pMTBAAJ" rel="noreferrer" target="_blank">https://groups.google.com/g/llvm-dev/c/u07o3QREVUg/m/uVlV3pMTBAAJ</a> and<br>
> > ><br>
> <a href="https://groups.google.com/g/llvm-dev/c/u07o3QREVUg/m/wF5mu-dpBAAJ" rel="noreferrer" target="_blank">https://groups.google.com/g/llvm-dev/c/u07o3QREVUg/m/wF5mu-dpBAAJ</a>)<br>
> > > whether I should move this to a pitch, but feel like there<br>
> wasn't a<br>
> > > clear response in the context of Renato's support tiers RFC.<br>
> > ><br>
> > > It seems like Tom and Renato still disagree about whether I<br>
> > should move<br>
> > > this to a pitch. I would appreciate some consensus on that<br>
> point at<br>
> > > least :-D I do see the appeal of a living document for<br>
> this sort of<br>
> > > thing, so definitely see the appeal there, but also it<br>
> seems like<br>
> > the<br>
> > > pitch process is a heavier-weight and more unusual one, so<br>
> I was<br>
> > > hesitant. My inclination is to continue this as an RFC<br>
> unless we are<br>
> > > unable to reach consensus on the issue as outlined in the<br>
> pitch<br>
> > process<br>
> > > description. It does feel like this is really not quite as<br>
> big a<br>
> > > decision as you seem to be suggesting. It's also an easily<br>
> > reversible<br>
> > > one since there are no build dependencies and everything is<br>
> > contained.<br>
> > ><br>
> ><br>
> > I still think this should be a pitch. The original mailing list<br>
> > discussion was controversial and that's when an RFC should be<br>
> escalated<br>
> > to a pitch according to: [1].<br>
> ><br>
> ><br>
> > You may have missed it, but in the meantime there has been<br>
> another RFC<br>
> > clarifying our policy though:<br>
> <a href="https://llvm.org/docs/SupportPolicy.html" rel="noreferrer" target="_blank">https://llvm.org/docs/SupportPolicy.html</a><br>
> > It seems fair to me to revisit this RFC as is in light of the<br>
> policy change.<br>
> ><br>
> <br>
> I don't think the questions about whether or not this should be<br>
> included<br>
> in the project are answered by this new policy. <br>
> <br>
> <br>
> I'll quote the policy:<br>
> <br>
> > Section: "What is covered"<br>
> > The peripheral tier is composed of:<br>
> > Experimental targets and options that haven’t been enable by default yet.<br>
> > Main repository projects that don’t get released or regularly tested.<br>
> > Legacy tools and scripts that aren’t used in upstream validation.<br>
> > *Alternative build systems (ex. GN, Bazel) and related infrastructure.*<br>
> <br>
> The intent of the policy is to cover exactly this proposal.<br>
> <br>
<br>
My understanding of the policy is that these categories of things still <br>
need to be approved in order to be added to the tree. Am I correct, or <br>
does this policy allow anyone to add an alternative build system as long <br>
as they can satisfy the support requirements.<br></blockquote><div><br></div><div>I agree with you, but that does not make it a justification for a pitch automatically.</div><div>The policy gives us a framework to discuss and avoids to rehash the same set of arguments over and over: for example we don't object to a specific proposal because we don't agree with the policy, but because of the specifics of a particular proposal.</div><div>Similarly, an RFC or a pitch shouldn't have to re-evaluate what has been codified as OK in a policy, otherwise what is the point of codifying it in the first place if everything is always revisited?</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<br>
> To me the part about<br>
> how the bazel build files were going to be supported and what<br>
> responsibility the community had for maintaining them was always<br>
> very clear.<br>
> <br>
> > I'd actually like to request that the objections are reiterated and<br>
> > positioned in terms of the policy before we escalate this.<br>
> ><br>
> <br>
> I don't think it's really fair to ask people to re-object to the<br>
> proposal. <br>
> <br>
> <br>
> Why?<br>
> The objections were mostly answered and have been addressed in the <br>
> policy. I don't quite get what you would put in a "pitch" while the <br>
> informations are outdated by the policy.<br>
> On the contrary it seems not only fair to me, but necessary.<br>
<br>
I don't really agree that all the objections were addressed. Maybe we <br>
should directly reach out to people from the original thread and ask them?<br></blockquote><div><br></div><div>Seems like we agree in the end: we need the objections to be restated :)</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<br>
I'm not really a fan of having another build system in tree, but I also <br>
don't want to keep devoting a lot of time to arguing about it. I was <br>
hoping that with the pitch process, we could avoid the kind of back and <br>
forth arguing on the list that typically make these RFCs so tiring.<br>
<br>
I still don't quite understand why there is so much push back against <br>
pitches, but I think everyone knows my perspective now, so I'm going to <br>
step back and let other people work out what the next steps should be.<br></blockquote><div><br></div><div>Can only speak for myself: I believe pitches should be more of a "last resort" than "the normal way of driving any proposal". I object to what I see using too easily a "pitch" as a way to "work around discussions".</div><div><br></div><div>-- </div><div>Mehdi</div><div><br></div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<br>
-Tom<br>
<br>
> In my opinion, one of the problems with RFCs in the past is<br>
> that they turn into an endurance test, because there is no process for<br>
> making a decision. Either the proposer gets tired of asking and gives<br>
> up or the objectors get tired of objecting and give up. We have a<br>
> decision process now with the pitch process, and I think we should<br>
> use it<br>
> <br>
> <br>
> We have to use it when we can't do otherwise. And again, I disagree that <br>
> this is a case without having objection formulated in light of the policy.<br>
> <br>
> <br>
> <br>
> <br>
> ><br>
> > Thank you for responding to my technical concerns, and I<br>
> agree that<br>
> > working out most of those details may be better left for a<br>
> patch review<br>
> > discussion. But I think at least the presence of build<br>
> information for<br>
> > other projects and the sub-module alternative should be<br>
> mentioned in<br>
> > the<br>
> > pitch.<br>
> ><br>
> > If there were only technical or support policy issues like<br>
> these to<br>
> > resolve then I don't think this would be controversial and<br>
> require a<br>
> > pitch.<br>
> ><br>
> > My main issue with this RFC, (which I tried to address at the<br>
> end of my<br>
> > previous mail), is the precedent this sets for what gets<br>
> included in<br>
> > tree. Essentially, we have a subset of our community that<br>
> chose to<br>
> > go a<br>
> > different direction from upstream, as always there are costs and<br>
> > benefits with this decision. The question for the community<br>
> is do we<br>
> > want to help or encourage this in the future by removing some<br>
> of the<br>
> > costs of these decisions and allowing alternative<br>
> implementations to<br>
> > live in tree.<br>
> ><br>
> > Maybe for build systems this is OK, and for other things this<br>
> is not,<br>
> > I don't know. But if we are going to be setting a precedent,<br>
> to me,<br>
> > the<br>
> > best way to do this is through the pitch process.<br>
> ><br>
> ><br>
> > Why are you considering this "setting a precedent" while there is<br>
> > already GN in tree?<br>
> ><br>
> <br>
> You are right we are not really setting a precedent here, because GN is<br>
> already in tree. However, I don't think we should now just allow any<br>
> build system to be added to the tree just because GN is there. We need<br>
> to have some kind of process and criteria for deciding what gets added<br>
> and what doesn't. I think a pitch will help accomplish this.<br>
> <br>
> I'll be honest, I don't really understand why there is so much push<br>
> back<br>
> on turning this into a pitch. Is it really that much extra work?<br>
> <br>
> -Tom<br>
> <br>
> > --<br>
> > Mehdi<br>
> ><br>
> ><br>
> ><br>
> ><br>
> > -Tom<br>
> ><br>
> ><br>
> ><br>
> ><br>
> ><br>
> ><br>
> ><br>
> ><br>
> ><br>
> ><br>
> ><br>
> ><br>
> ><br>
> > [1]<br>
> ><br>
> <a href="https://github.com/llvm/llvm-www/blob/master/proposals/LP0001-LLVMDecisionMaking.md" rel="noreferrer" target="_blank">https://github.com/llvm/llvm-www/blob/master/proposals/LP0001-LLVMDecisionMaking.md</a><br>
> ><br>
> > > On Mon, Nov 16, 2020 at 9:41 PM Tom Stellard<br>
> <<a href="mailto:tstellar@redhat.com" target="_blank">tstellar@redhat.com</a> <mailto:<a href="mailto:tstellar@redhat.com" target="_blank">tstellar@redhat.com</a>><br>
> > <mailto:<a href="mailto:tstellar@redhat.com" target="_blank">tstellar@redhat.com</a> <mailto:<a href="mailto:tstellar@redhat.com" target="_blank">tstellar@redhat.com</a>>><br>
> > > <mailto:<a href="mailto:tstellar@redhat.com" target="_blank">tstellar@redhat.com</a> <mailto:<a href="mailto:tstellar@redhat.com" target="_blank">tstellar@redhat.com</a>><br>
> <mailto:<a href="mailto:tstellar@redhat.com" target="_blank">tstellar@redhat.com</a> <mailto:<a href="mailto:tstellar@redhat.com" target="_blank">tstellar@redhat.com</a>>>>> wrote:<br>
> > ><br>
> > > > This should have approximately the same impact on the<br>
> > community<br>
> > > as the<br>
> > > > current GN build in `llvm/utils/gn` does today.<br>
> That is, it<br>
> > > should not<br>
> > > > affect anyone who doesn't care.<br>
> > > ><br>
> > ><br>
> > > I want to push back on this a little bit, because<br>
> having the<br>
> > code in<br>
> > > tree does impact everyone, even people who don't care<br>
> about<br>
> > it. It<br>
> > > increases disk usage, commit traffic, checkout times,<br>
> > bugzilla / issue<br>
> > > traffic, and CI builds to name a few things. There<br>
> are costs<br>
> > to having<br>
> > > this in tree, the question (as always) is do the benefits<br>
> > outweigh the<br>
> > > costs?<br>
> > ><br>
> > > Yes my apologies that this was poorly phrased. I was<br>
> aiming for a<br>
> > pithy<br>
> > > summary and a clear statement that our goal here is not to<br>
> > significantly<br>
> > > impact contributors uninterested in Bazel. My impression<br>
> is that<br>
> > the GN<br>
> > > build has achieved that goal. I definitely agree that any<br>
> > addition to<br>
> > > the monorepo should have a clear weighing of costs vs benefits<br>
> > and that<br>
> > > the costs are never actually zero. I do think the costs<br>
> here are<br>
> > really<br>
> > > quite low however. I am happy to address your concerns and<br>
> also<br>
> > think<br>
> > > that it is important to note that if additional issues<br>
> arise we are<br>
> > > still agreeing to be on the hook for addressing them (e.g.<br>
> if in<br>
> > > practice this causes some unforseen issue with the<br>
> release) and<br>
> > deleting<br>
> > > this contribution if we cannot do so in a timely manner<br>
> (`rm -rf<br>
> > > utils/bazel` is all it requires).<br>
> > ><br>
> > > Personally, I do not think we should have alternative<br>
> build<br>
> > systems in<br>
> > > tree. However, I still think you should try to<br>
> propose this<br>
> > as a pitch.<br>
> > > I would much rather this go through a fair process and<br>
> land<br>
> > than for it<br>
> > > to be rejected based on a contentious thread.<br>
> > ><br>
> > > Here is why I'm not convinced this should be in tree:<br>
> > ><br>
> > > To me it's not clear why having the build files in-tree is<br>
> > better than<br>
> > > having a separate repo with an llvm-project<br>
> sub-module. The<br>
> > in tree<br>
> > > bazel files will be broken from time to time, since most<br>
> > developers will<br>
> > > not be updating them, however, with the sub-module<br>
> approach<br>
> > you can<br>
> > > ensure that the build will always work by pinning the<br>
> llvm-bazel<br>
> > > repo to<br>
> > > a known-working commit of llvm-project. Can you<br>
> expand on the<br>
> > > pros/cons<br>
> > > of in-tree vs out-of-tree with sub-modules.<br>
> > ><br>
> > > Out-of-tree with a submodule is the current approach we<br>
> have with<br>
> > > <a href="https://github.com/google/llvm-bazel" rel="noreferrer" target="_blank">https://github.com/google/llvm-bazel</a>. It's certainly<br>
> doable, but<br>
> > > involves quite a bit of bookkeeping to track which version<br>
> > corresponds<br>
> > > to a given version of LLVM such that someone can fetch the<br>
> correct<br>
> > > configuration (you'll note that the repository has about<br>
> 7k tags<br>
> > at the<br>
> > > moment). To make things somewhat more complicated, the typical<br>
> > way to<br>
> > > fetch something for use in Bazel is with an http_archive<br>
> > ><br>
> > <br>
> <<a href="https://docs.bazel.build/versions/master/repo/http.html#http_archive" rel="noreferrer" target="_blank">https://docs.bazel.build/versions/master/repo/http.html#http_archive</a>> which<br>
> ><br>
> > > requires one to specify the archive digest to avoid<br>
> refetching on<br>
> > each<br>
> > > build. This doesn't work particularly well with tags that<br>
> change<br>
> > which<br>
> > > commit they point to. I'm not saying these issues aren't<br>
> > solvable, but<br>
> > > they add quite a bit of complexity.<br>
> > ><br>
> > > The other point is that I think this makes contributing to<br>
> the Bazel<br>
> > > configuration quite a bit more complex because you have to<br>
> apply<br>
> > patches<br>
> > > across multiple repositories to also be kept in sync.<br>
> Given that<br>
> > LLVM<br>
> > > has a monorepo, it still seems like the logical place for<br>
> a build<br>
> > > configuration of LLVM used by multiple projects.<br>
> > ><br>
> > > Other concerns I have from reviewing the patch:<br>
> > ><br>
> > > It seems like these are mostly concerns with the specific<br>
> > > implementation. Would you be alright with saving the specific<br>
> > details<br>
> > > for an eventual review on the patch if this moves forward?<br>
> I've made<br>
> > > brief responses below.<br>
> > ><br>
> > > * It looks like there is a build configuration for at<br>
> least one<br>
> > > external<br>
> > > project (zlib) and possibly another<br>
> (vulkan-headers?). Do we<br>
> > really<br>
> > > want to have build configurations for non-LLVM<br>
> projects in our<br>
> > > tree? Is<br>
> > > there any limit to the number of external projects<br>
> that can<br>
> > and will be<br>
> > > added?<br>
> > ><br>
> > > These are dependencies of the LLVM Project and LLVM keeps its<br>
> > > dependencies pretty tightly managed AFAIU. These<br>
> configurations<br>
> > are also<br>
> > > pretty trivial, "here are the source files", type things,<br>
> so I think<br>
> > > it's even a bit generous to call them configurations:<br>
> we're just<br>
> > > informing Bazel where the files are located.<br>
> > ><br>
> > ><br>
> > > * There are 3 files (abi-breaking.h.cmake, config.h.cmake,<br>
> > > llvm-config.h.cmake) that have been copied from the<br>
> llvm tree<br>
> > into<br>
> > > utils/bazel/, is there some way we can avoid carrying<br>
> multiple<br>
> > > copies of<br>
> > > the same file in tree?<br>
> > ><br>
> > ><br>
> > > * Similarly, there are some files that are normally<br>
> generated<br>
> > at build<br>
> > > time clang/Config/config.h, llvm/Config/config.h,<br>
> > > llvm/Config/llvm-config.h that have been copied into<br>
> > utils/bazel.<br>
> > > Is it<br>
> > > really necessary<br>
> > > to have these in tree? Especially since some of the<br>
> > templates, like<br>
> > > llvm-config.h.cmake, are also in utils/bazel?<br>
> > ><br>
> > > The copy here is pretty much orthogonal to the actual build<br>
> > > configuration. The intent is to have a literal change detector<br>
> > test for<br>
> > > changes to these cmake configurations, since they would<br>
> invalidate<br>
> > > assumptions in the Bazel configuration. Chandler and I<br>
> went back and<br>
> > > forth on a few different ways to do this. We can certainly<br>
> look<br>
> > at other<br>
> > > options. The issue is that I don't think there's actually a<br>
> > useful way<br>
> > > to interpret the .cmake template files since changes to<br>
> them are<br>
> > also<br>
> > > made as changes to the cmake configuration and without these<br>
> > being in<br>
> > > sync the files just drift. Happy to discuss other options<br>
> for how to<br>
> > > handle this. We could, for instance, have some other<br>
> process that<br>
> > just<br>
> > > looks at the git diff/log for these files.<br>
> > ><br>
> > > * I still worry about the bazel files causing merging<br>
> > conflicts when<br>
> > > backported to the stable branch. If these are added<br>
> to tree,<br>
> > could we<br>
> > > have a rule where commits to utils/bazel/ cannot include<br>
> > changes to<br>
> > > other files?<br>
> > ><br>
> > > I'd certainly be open to discussing restrictions that<br>
> would avoid<br>
> > > additional burden on release managers. I think that one makes<br>
> > > contributing to the Bazel configuration more difficult<br>
> because you<br>
> > > cannot do it as part of a patch that requires a change,<br>
> but if it's<br>
> > > something that would cause issues with the release then we can<br>
> > avoid it.<br>
> > > My intuition is that this wouldn't actually come up often,<br>
> > however. For<br>
> > > example, just looking at the gn directory I see several<br>
> commits<br>
> > in the<br>
> > > last week that touch this and other files. Have you<br>
> actually run<br>
> > into<br>
> > > issues? Since this is unsupported the conflicts could also be<br>
> > resolved<br>
> > > pretty much however you wanted (e.g. delete the conflict<br>
> markers,<br>
> > delete<br>
> > > the file), so they seem pretty trivial to deal with if<br>
> they only<br>
> > happen<br>
> > > occasionally. My preference would therefore be to see if<br>
> this is<br>
> > > actually a problem in practice before putting rules in place.<br>
> > ><br>
> > ><br>
> > > On Tue, Nov 17, 2020 at 2:27 AM Renato Golin<br>
> <<a href="mailto:rengolin@gmail.com" target="_blank">rengolin@gmail.com</a> <mailto:<a href="mailto:rengolin@gmail.com" target="_blank">rengolin@gmail.com</a>><br>
> > <mailto:<a href="mailto:rengolin@gmail.com" target="_blank">rengolin@gmail.com</a> <mailto:<a href="mailto:rengolin@gmail.com" target="_blank">rengolin@gmail.com</a>>><br>
> > > <mailto:<a href="mailto:rengolin@gmail.com" target="_blank">rengolin@gmail.com</a> <mailto:<a href="mailto:rengolin@gmail.com" target="_blank">rengolin@gmail.com</a>><br>
> <mailto:<a href="mailto:rengolin@gmail.com" target="_blank">rengolin@gmail.com</a> <mailto:<a href="mailto:rengolin@gmail.com" target="_blank">rengolin@gmail.com</a>>>>> wrote:<br>
> > ><br>
> > > Hi Geoffrey,<br>
> > ><br>
> > > Thanks for the re-submission.<br>
> > ><br>
> > > I have some comments below that may sound negative,<br>
> but they're<br>
> > > probably just a reflection of my own ignorance. I want to<br>
> > make sure<br>
> > > the submission is clear, so it can be accepted on its<br>
> own right.<br>
> > ><br>
> > > On Tue, 17 Nov 2020 at 03:02, Geoffrey Martin-Noble<br>
> via llvm-dev<br>
> > > <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
> <mailto:<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> <mailto:<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
> <mailto:<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>>><br>
> > <mailto:<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
> <mailto:<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> <mailto:<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
> <mailto:<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>>>>><br>
> > wrote:<br>
> > ><br>
> > > This should not affect development of core tier<br>
> components.<br>
> > > One reason we propose adding this to the root utils/<br>
> > directory<br>
> > > instead of under llvm/utils (where GN is located)<br>
> is to avoid<br>
> > > unnecessarily sending messages to llvm-commits.<br>
> Others have<br>
> > > raised the concern that the existence of an<br>
> alternative build<br>
> > > system might lead to lack of maintenance for the<br>
> CMake build<br>
> > > system. Given that supporting CMake will remain a<br>
> requirement<br>
> > > and maintenance of a Bazel build system will<br>
> continue to<br>
> > happen<br>
> > > regardless, we do not expect any significant impact in<br>
> > this way.<br>
> > ><br>
> > ><br>
> > > I was under the impression that "utils" was actually<br>
> > "llvm/utils",<br>
> > > which would be in the same place as GN. I don't think<br>
> we should<br>
> > > treat GN and Bazel as different and I really wouldn't<br>
> like to<br>
> > have a<br>
> > > different quality control (for post commit reviews).<br>
> > ><br>
> > > If the Bazel commits are too verbose (for example,<br>
> committing<br>
> > > auto-generated code), then we should really clean that<br>
> up and<br>
> > commit<br>
> > > the script that generates them and make that part of<br>
> the build.<br>
> > ><br>
> > > I understand the need to move the noise away, but move<br>
> it too far<br>
> > > away and it's no better than in a separate repo.<br>
> > ><br>
> > > I am happy to put this in either location and agree it<br>
> should be<br>
> > in the<br>
> > > same place as GN. If we were to decide that it should go<br>
> `utils/`<br>
> > then I<br>
> > > would also propose we move GN to there as well. I believe<br>
> the GN<br>
> > files<br>
> > > were contributed prior to the existence of the monorepo, so a<br>
> > top-level<br>
> > > `utils/` wouldn't have been an option. I think living<br>
> under the root<br>
> > > `utils/` directory makes more sense because these are not<br>
> > configurations<br>
> > > for only the LLVM subproject (we also build MLIR and Clang<br>
> with<br>
> > perhaps<br>
> > > more to come). I believe it was Mehdi's suggestion that this<br>
> > would help<br>
> > > mitigate some of the costs to having it in the monorepo<br>
> because Tom<br>
> > > mentioned commit list traffic as a concern. I don't think<br>
> I agree<br>
> > that<br>
> > > one directory up is akin to a separate repo though :-D<br>
> > ><br>
> > > That said, this is a really minor point for me. I'm happy<br>
> to put<br>
> > this<br>
> > > wherever people prefer :-)<br>
> > ><br>
> > ><br>
> > > A number of people raised the question of "why not<br>
> a separate<br>
> > > repository". This is indeed possible: It's what we've<br>
> > done with<br>
> > > <a href="https://github.com/google/llvm-bazel" rel="noreferrer" target="_blank">https://github.com/google/llvm-bazel</a>, which is currently<br>
> used by<br>
> > > <a href="https://github.com/google/iree" rel="noreferrer" target="_blank">https://github.com/google/iree</a>. It is significantly more<br>
> > > infrastructure, coordination, and complexity for<br>
> > something that<br>
> > > is specifically a configuration for the LLVM project<br>
> > itself, not<br>
> > > its own dependent or adjacent project.<br>
> > ><br>
> > ><br>
> > > I was also under the impression that one of the big<br>
> reasons<br>
> > why we<br>
> > > needed it to be in LLVM is that, like CMake, it needed<br>
> files all<br>
> > > over the place. This would indeed be a major<br>
> infrastructure<br>
> > undertaking.<br>
> > ><br>
> > > But given that it's all being hosted in a single<br>
> directory, and<br>
> > > outside of the LLVM tree, I really can't see what's so<br>
> much<br>
> > harder<br>
> > > about an extra checkout in the same tree.<br>
> > ><br>
> > > Bazel *wants* the build files to be all over the place,<br>
> but I've<br>
> > tricked<br>
> > > it with some repository rule symlinking. That's also true<br>
> of the<br>
> > LLVM GN<br>
> > > configuration, I believe. My assumption is that having<br>
> BUILD files<br>
> > > actually throughout the repository would be something that<br>
> would<br>
> > receive<br>
> > > quite a bit of pushback and would be confusing for people<br>
> who would<br>
> > > naturally expect these BUILD files to be maintained as a<br>
> > supported build<br>
> > > system. I would happily put a BUILD.bazel file at the root<br>
> of each<br>
> > > subproject and drop the symlinking madness, but I suspect this<br>
> > would not<br>
> > > be embraced as a solution ;-P<br>
> > ><br>
> > ><br>
> > > I believe this contribution will significantly<br>
> improve the<br>
> > > situation for downstream users that use Bazel<br>
> while having<br>
> > > minimal impact on the community at large.<br>
> > ><br>
> > ><br>
> > > It's not clear to me yet if LLVM/Bazel is only used in<br>
> Google<br>
> > > projects or any other non-Google project. All that you<br>
> listed<br>
> > so far<br>
> > > seem to be exclusive to Google.<br>
> > ><br>
> > > This is not a problem per se, but it does promote the<br>
> idea that<br>
> > > Google could common it up internally instead.<br>
> > ><br>
> > > The main reasons why it would be upstream are that<br>
> it's either a<br>
> > > product by or requirement to the project itself, or it<br>
> helps<br>
> > unite<br>
> > > cross-industry collaboration that wouldn't be possible<br>
> otherwise.<br>
> > ><br>
> > > It's clearly not the former (and why it's in the<br>
> periphery tier),<br>
> > > but it's also not clear it's in the latter either.<br>
> > ><br>
> > > I can really only speak for Google projects. I have also<br>
> noticed<br>
> > several<br>
> > > other Bazel build configurations in the wild, e.g. PlaidML<br>
> > ><br>
> > <br>
> <<a href="https://github.com/plaidml/plaidml/blob/master/vendor/llvm/llvm.BUILD" rel="noreferrer" target="_blank">https://github.com/plaidml/plaidml/blob/master/vendor/llvm/llvm.BUILD</a>> (Intel)<br>
> ><br>
> > > or this bazel_llvm<br>
> > <<a href="https://github.com/ChrisCummins/bazel_llvm" rel="noreferrer" target="_blank">https://github.com/ChrisCummins/bazel_llvm</a>> project<br>
> > > that I found after someone contributed a doc fix. I believe in<br>
> > the last<br>
> > > thread someone from Facebook mentioned that Bazel build files<br>
> > would also<br>
> > > be relatively easily translatable to their internal<br>
> Bazel-derived<br>
> > build<br>
> > > system, Buck. Someone from Lyft also expressed interest in<br>
> using<br>
> > a Bazel<br>
> > > build configuration if it was in-tree. But I can't really<br>
> speak<br>
> > to the<br>
> > > motivations, road maps, etc. for any of these people,<br>
> companies, or<br>
> > > projects (if you're reading, please chime in ;-P).<br>
> > ><br>
> ><br>
> > _______________________________________________<br>
> > LLVM Developers mailing list<br>
> > <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a> <mailto:<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>><br>
> <mailto:<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a> <mailto:<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>>><br>
> > <a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
> ><br>
> <br>
<br>
</blockquote></div></div>