<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Oct 29, 2020 at 2:35 PM Chris Tetreault <<a href="mailto:ctetreau@quicinc.com">ctetreau@quicinc.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">
<div lang="EN-US">
<div class="gmail-m_252693444111276080WordSection1">
<p class="MsoNormal">Honestly, I’m hearing that some people would like the Bazel build system to be in community master, and the argument basically boils down to “It’ll be fine. It’ll just sit there and mind its own business and you don’t have to care about
it.”</p></div></div></blockquote><div><br></div><div>Not really: this argument is only the answer to why it does not bear any weight on non-Bazel users, just like `gn` does already today.</div><div><br></div><div>I think I explained the motivation to do it, but I can restate it: many LLVM contributors need to collaborate on this piece of infrastructure that is very specific to LLVM and enabling some users of LLVM: the natural place of collaboration is the monorepo. </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"><div lang="EN-US"><div class="gmail-m_252693444111276080WordSection1"><p class="MsoNormal"><u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">> So why are we doing it? I mentioned this in another answer: this is mainly to provide a collaboration space for the support of OSS projects using Bazel interested to use LLVM (and some subprojects). …<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Which could be handled by having it in an external public repo.</p></div></div></blockquote><div><br></div><div>Sure, just like almost every new code could be handled in an external repo. However when many LLVM contributors are interested to collaborate on something highly coupled to LLVM it seems like the natural place to do it.</div><div>Also I don't know for Qualcomm, but most companies will want you to sign a CLA if they provide this "external repo" where we can collaborate, and other parties won't be able to collaborate. The LLVM project is in general seen as quite "neutral" for collaborating.</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"><div lang="EN-US"><div class="gmail-m_252693444111276080WordSection1"><p class="MsoNormal"><u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">> Having them in-tree means that we can publish every day (or more) a git hash that we validate with Bazel on private bots (like `gn`) and every project can use to clone the LLVM monorepo and integrate in their build flow easily.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">You could still publish this info: “Today, the head of llvm-bazel is confirmed to work with LLVM monorepo sha [foo]”. I don’t think two git clones is significantly harder than one.</p></div></div></blockquote><div><br></div><div>For a developer at their desk, you could say it is just an inconvenience that can be worked around (scripting, etc.). </div><div>For the project on the other hand, Bazel has native support to clone a repo and build it itself as dependency. For example TensorFlow has many dependencies, and it just points to a commit in the source repo: <a href="https://github.com/tensorflow/tensorflow/blob/master/tensorflow/workspace.bzl#L689-L697">https://github.com/tensorflow/tensorflow/blob/master/tensorflow/workspace.bzl#L689-L697</a></div><div>You can see how it is convenient to update the SHA1 there and have it just work for any Bazel user.</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"><div lang="EN-US"><div class="gmail-m_252693444111276080WordSection1"><p class="MsoNormal"> I submit that in a way this is simpler because you can
always advertise the head of the bazel repo. If the Bazel build system were in the community repo, then you might have to tell users to use an older version of the bazel build if a fix went into the monorepo in the afternoon, but the next morning’s nightly
finds that the most recent sha that passes the tests is prior to that fix.</p></div></div></blockquote><div><br></div><div>This is not different from "a commit broke the ARM bootstrap and a user who checked out the repo at the time will be broken". From this point of view this configuration is no different than any other, except that we don't revert or notify the author of a breaking change, a set of volunteers monitor a silent bot and fix-forward as needed, like `gn`.</div><div>It is just much easier to have a bot publishing the "known good" revision of the monorepo.<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"><div lang="EN-US"><div class="gmail-m_252693444111276080WordSection1">
<p class="MsoNormal">I guess my concern is that I’m not really hearing a compelling (to my ear) argument for this inclusion. </p></div></div></blockquote><div><br></div><div>Sure, but if other contributors have a strong interest, and you don't really have a strong objection here that we need to address, we should be able to get past that?</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"><div lang="EN-US"><div class="gmail-m_252693444111276080WordSection1"><p class="MsoNormal">I guess it would make the lives of google employees easier? </p></div></div></blockquote><div><br></div><div>I explained before that Google internal integration flow is likely better without this at the moment, TensorFlow itself is also in a reasonably good spot at the moment. But Google is also not a monolithic place, some people are working on small independent projects that they are open-sourcing, and would like to be able to use LLVM. </div><div><br></div><div>> <span style="orphans: 2; widows: 2;"> </span><span style="orphans: 2; widows: 2;">Then what’s to stop every large org from committing their internal stuff to master?</span></div><p class="MsoNormal" style="font-variant-ligatures:normal"><u></u></p><span class="gmail-im" style="font-variant-ligatures:normal"><p class="MsoNormal"><u></u> </p><p class="MsoNormal">If their "internal stuff" is highly-coupled to LLVM, has zero-cost maintenance on the community, and is something that multiple other parties can benefit and established members of the community want to maintain and collaborate on, why not?</p><p class="MsoNormal"><br></p><p class="MsoNormal">I mentioned it before, but Bazel is not something internal or specific to Google: it isn't (actually there are many incompatibilities between Bazel and the internal system), 400 people attended the Bazel conference last year. I attended this conference 3 years ago when I was at Tesla trying to deploy Bazel internally. Many other companies are using Bazel, open-source projects as well. Feel free to watch the talks online about <a href="https://www.youtube.com/watch?v=t_3bckhV_YI">SpaceX</a> or <a href="https://www.youtube.com/watch?v=_bPyEbAyC0s">Two Sigma and Uber</a> for example</p><p class="MsoNormal"><br></p><p class="MsoNormal">I'm not trying to convince anyone to use Bazel, it has drawbacks, but the point here is to recognize that this is about OpenSource communities that Bazel is serving: these are users, some of us in the LLVM community are trying to provide these users with a reasonably good integration story, and we're ready to pay the cost for everyone.</p></span><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"><div lang="EN-US"><div class="gmail-m_252693444111276080WordSection1"><p class="MsoNormal"><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal"><b>From:</b> Mehdi AMINI <<a href="mailto:joker.eph@gmail.com" target="_blank">joker.eph@gmail.com</a>> <br>
<b>Sent:</b> Thursday, October 29, 2020 2:00 PM<br>
<b>To:</b> Chris Tetreault <<a href="mailto:ctetreau@quicinc.com" target="_blank">ctetreau@quicinc.com</a>><br>
<b>Cc:</b> Sterling Augustine <<a href="mailto:saugustine@google.com" target="_blank">saugustine@google.com</a>>; Mehdi Amini <<a href="mailto:aminim@google.com" target="_blank">aminim@google.com</a>>; LLVM Dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>>; Stella Laurenzo <<a href="mailto:laurenzo@google.com" target="_blank">laurenzo@google.com</a>>; Tres Popp <<a href="mailto:tpopp@google.com" target="_blank">tpopp@google.com</a>>; Geoffrey Martin-Noble <<a href="mailto:gcmn@google.com" target="_blank">gcmn@google.com</a>>; Thomas Joerg <<a href="mailto:tjoerg@google.com" target="_blank">tjoerg@google.com</a>><br>
<b>Subject:</b> [EXT] Re: [llvm-dev] Contributing Bazel BUILD files similar to gn<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<p class="MsoNormal">On Thu, Oct 29, 2020 at 1:24 PM Chris Tetreault via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<u></u><u></u></p>
</div>
<blockquote style="border-style:none none none solid;border-left-width:1pt;border-left-color:rgb(204,204,204);padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<p class="MsoNormal">The problem is that once it’s in community LLVM, it becomes the community’s problem. The expectation is that individual contributors do not break anything in upstream.<u></u><u></u></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">I would expect that the community by now has concrete experience with `gn` gained over a few years demonstrating that this hasn't been a problem to have this in-tree, without a burden of support on the community.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">In particular, I think that a salient point is the guarantee that no public bot would be testing it (I mean here by "no public bot" that no bot would email you when you break it).<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<blockquote style="border-style:none none none solid;border-left-width:1pt;border-left-color:rgb(204,204,204);padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<p class="MsoNormal">Why else would you contribute it to the LLVM monorepo? If the goal is just to enable external-to-google orgs to collaborate on it, why not contribute it as a new repo separate from
LLVM? You wouldn’t need to ask anybody’s permission to do this.<u></u><u></u></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Yes, we could do this, and you are correct that in many cases a motivation to upstream a component is to make sure it is maintained by the community and works out of the box. <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">In this case it is slightly different: we are OK with people to break this. We are already maintaining these files out-of-tree for our own purposes, and this has been the case for years as Sterling mentions. I would even suspect that for
Google internal build integration, it is actually easier to have these files internal only rather than unsupported upstream.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">So why are we doing it? I mentioned this in another answer: this is mainly to provide a collaboration space for the support of OSS projects using Bazel interested to use LLVM (and some subprojects).<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">Having them in-tree means that we can publish every day (or more) a git hash that we validate with Bazel on private bots (like `gn`) and every project can use to clone the LLVM monorepo and integrate in their build flow easily. Another
repo, submodules, etc. are not making this possible / practical.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<blockquote style="border-style:none none none solid;border-left-width:1pt;border-left-color:rgb(204,204,204);padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal"><b>From:</b> Sterling Augustine <<a href="mailto:saugustine@google.com" target="_blank">saugustine@google.com</a>>
<br>
<b>Sent:</b> Thursday, October 29, 2020 1:14 PM<br>
<b>To:</b> Chris Tetreault <<a href="mailto:ctetreau@quicinc.com" target="_blank">ctetreau@quicinc.com</a>><br>
<b>Cc:</b> Renato Golin <<a href="mailto:rengolin@gmail.com" target="_blank">rengolin@gmail.com</a>>;
<a href="mailto:tstellar@redhat.com" target="_blank">tstellar@redhat.com</a>; Mehdi Amini <<a href="mailto:aminim@google.com" target="_blank">aminim@google.com</a>>; LLVM Dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>>;
Stella Laurenzo <<a href="mailto:laurenzo@google.com" target="_blank">laurenzo@google.com</a>>; Tres Popp <<a href="mailto:tpopp@google.com" target="_blank">tpopp@google.com</a>>; Geoffrey Martin-Noble <<a href="mailto:gcmn@google.com" target="_blank">gcmn@google.com</a>>;
Thomas Joerg <<a href="mailto:tjoerg@google.com" target="_blank">tjoerg@google.com</a>><br>
<b>Subject:</b> [EXT] Re: [llvm-dev] Contributing Bazel BUILD files similar to gn<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<div>
<div>
<p class="MsoNormal">On Thu, Oct 29, 2020 at 12:29 PM Chris Tetreault via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<u></u><u></u></p>
</div>
<div>
<blockquote style="border-style:none none none solid;border-left-width:1pt;border-left-color:rgb(204,204,204);padding:0in 0in 0in 6pt;margin:5pt 0in 5pt 4.8pt">
<div>
<div>
<p class="MsoNormal">I think Renato has articulated quite well some concerns I have about this but was unable to express. I would very much prefer if we just focus on using CMake effectively.<u></u><u></u></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal">... <u></u><u></u></p>
</div>
<blockquote style="border-style:none none none solid;border-left-width:1pt;border-left-color:rgb(204,204,204);padding:0in 0in 0in 6pt;margin:5pt 0in 5pt 4.8pt">
<div>
<div>
<p class="MsoNormal">For example, when trying to implement the same logic on both will not be trivial. So, whenever we want to add some functionality or improve how we build LLVM with one system, we'll
have to do so in multiple build systems that do not easily match each other. <u></u>
<u></u></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">Google already does all of this work, and has for years. I think it is fair to say that it hasn't been a burden on the community.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<blockquote style="border-style:none none none solid;border-left-width:1pt;border-left-color:rgb(204,204,204);padding:0in 0in 0in 6pt;margin:5pt 0in 5pt 4.8pt">
<div>
<div>
<p class="MsoNormal">If we don't try to match functionality, we'll segregate the community, because people will be able to do X on build system A but not B, and the similar features cluster together
and then we have essentially two projects built from the same source code.<u></u><u></u></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">As long as we keep CMake as the canonical system everything will be fine. It works perfectly well today, except that not everyone gets to see or use the bazel files. They exist
right now; they work right now; and it hasn't been a burden on anyone but the people who care about bazel.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<blockquote style="border-style:none none none solid;border-left-width:1pt;border-left-color:rgb(204,204,204);padding:0in 0in 0in 6pt;margin:5pt 0in 5pt 4.8pt">
<div>
<div>
<div>
<div>
<div>
<p class="MsoNormal">Testing this, or worse, trying to fix a buildbot that is built with Bazel (and having to install Java JDK and all its dependencies) on potentially a hardware that you do not have
access to, will be a nightmare to debug. The nature of post-commit testing, revert and review of LLVM will not make that simpler. Unless we treat the Bazel build as "not our problem" (which defeats the point of having it?).<u></u><u></u></p>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">Google makes it work like this today, with the rest of the project treating it as "not our problem" because they don't even see that they exist. The build bot issues would be real,
but I think surmountable, given that Google already cleans up the bazel files, it just doesn't push them. Perhaps an explicit policy that cmake folks don't have to update the bazel files would be helpful.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<blockquote style="border-style:none none none solid;border-left-width:1pt;border-left-color:rgb(204,204,204);padding:0in 0in 0in 6pt;margin:5pt 0in 5pt 4.8pt">
<div>
<div>
<div>
<p class="MsoNormal">To make matters worse, our CMake files are not simple, and do not do all of the things we want them to do in the way we understand completely. There is a lot of kludge that we carry
and with that comes in two categories: the things that we hate and would love to fix, and the things that are fixes that we have no idea are there. The former are the reasons why people want to start a new build system, the latter is why they soon realise
that was a mistake (insert XKCD joke here).<u></u><u></u></p>
</div>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">It wouldn't be starting a new build system, it would be making a pre-existing, already extremely well functioning one, available to more people.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">I can definitely see folks who use cmake not wanting more hassle--that may be a valid reason not to do it. But "it won't work" or "it's hard to keep up" or "it's too complicated"
seem well refuted by a multi-year existence proof.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
</div>
</div>
</div>
</div>
<p class="MsoNormal">_______________________________________________<br>
LLVM Developers mailing list<br>
<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" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><u></u><u></u></p>
</blockquote>
</div>
</div>
</div>
</div>
</blockquote></div></div></div></div></div></div>