<div dir="ltr"><div dir="ltr"><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 7:30 PM Johannes Doerfert <<a href="mailto:johannesdoerfert@gmail.com">johannesdoerfert@gmail.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">I replied only selectively.<br>
<br>
<br>
On 10/29/20 5:47 PM, Mehdi AMINI via llvm-dev wrote:<br>
> On Thu, Oct 29, 2020 at 2:35 PM Chris Tetreault <<a href="mailto:ctetreau@quicinc.com" target="_blank">ctetreau@quicinc.com</a>><br>
> wrote:<br>
><br>
>> Honestly, I’m hearing that some people would like the Bazel build system<br>
>> to be in community master, and the argument basically boils down to “It’ll<br>
>> be fine. It’ll just sit there and mind its own business and you don’t have<br>
>> to care about it.”<br>
>><br>
> Not really: this argument is only the answer to why it does not bear any<br>
> weight on non-Bazel users, just like `gn` does already today.<br>
><br>
> I think I explained the motivation to do it, but I can restate it: many<br>
> LLVM contributors need to collaborate on this piece of infrastructure that<br>
> is very specific to LLVM and enabling some users of LLVM: the natural place<br>
> of collaboration is the monorepo.<br>
><br>
><br>
>><br>
>>> So why are we doing it? I mentioned this in another answer: this is<br>
>> mainly to provide a collaboration space for the support of OSS projects<br>
>> using Bazel interested to use LLVM (and some subprojects). …<br>
>><br>
>><br>
>><br>
>> Which could be handled by having it in an external public repo.<br>
>><br>
> Sure, just like almost every new code could be handled in an external repo.<br>
> However when many LLVM contributors are interested to collaborate on<br>
> something highly coupled to LLVM it seems like the natural place to do it.<br>
> Also I don't know for Qualcomm, but most companies will want you to sign a<br>
> CLA if they provide this "external repo" where we can collaborate, and<br>
> other parties won't be able to collaborate. The LLVM project is in general<br>
> seen as quite "neutral" for collaborating.<br>
><br>
><br>
>><br>
>>> Having them in-tree means that we can publish every day (or more) a git<br>
>> hash that we validate with Bazel on private bots (like `gn`) and every<br>
>> project can use to clone the LLVM monorepo and integrate in their build<br>
>> flow easily.<br>
>><br>
>><br>
>><br>
>> You could still publish this info: “Today, the head of llvm-bazel is<br>
>> confirmed to work with LLVM monorepo sha [foo]”. I don’t think two git<br>
>> clones is significantly harder than one.<br>
>><br>
> For a developer at their desk, you could say it is just an inconvenience<br>
> that can be worked around (scripting, etc.).<br>
> For the project on the other hand, Bazel has native support to clone a repo<br>
> and build it itself as dependency.  For example TensorFlow has many<br>
> dependencies, and it just points to a commit in the source repo:<br>
> <a href="https://github.com/tensorflow/tensorflow/blob/master/tensorflow/workspace.bzl#L689-L697" rel="noreferrer" target="_blank">https://github.com/tensorflow/tensorflow/blob/master/tensorflow/workspace.bzl#L689-L697</a><br>
> You can see how it is convenient to update the SHA1 there and have it just<br>
> work for any Bazel user.<br>
><br>
><br>
><br>
>> I submit that in a way this is simpler because you can always advertise<br>
>> the head of the bazel repo. If the Bazel build system were in the community<br>
>> repo, then you might have to tell users to use an older version of the<br>
>> bazel build if a fix went into the monorepo in the afternoon, but the next<br>
>> morning’s nightly finds that the most recent sha that passes the tests is<br>
>> prior to that fix.<br>
>><br>
> This is not different from "a commit broke the ARM bootstrap and a user who<br>
> checked out the repo at the time will be broken". From this point of view<br>
> this configuration is no different than any other, except that we don't<br>
> revert or notify the author of a breaking change, a set of volunteers<br>
> monitor a silent bot and fix-forward as needed, like `gn`.<br>
> It is just much easier to have a bot publishing the "known good" revision<br>
> of the monorepo.<br>
><br>
><br>
>> I guess my concern is that I’m not really hearing a compelling (to my ear)<br>
>> argument for this inclusion.<br>
>><br>
> Sure, but if other contributors have a strong interest, and you don't<br>
> really have a strong objection here that we need to address, we should be<br>
> able to get past that?<br>
<br>
Wouldn't your argument hold for anything that "just lives" in the mono<br>
repo but doesn't impact people? I mean, where is the line for stuff that<br>
some contributors have "strong interest" in and others can't really<br>
"hear a compelling argument for inclusion"? People raise concerns here<br>
and from where I am sitting they are brushed over easily and more<br>
aggressively as the thread progresses (up to the email I respond to).<br></blockquote><div><br></div><div>Sorry, I invite you to reread the thread again and revisit your impression: Tom and Renato expressed clear concerns, and I believe I really tried to listen and address these with concrete proposals to mitigate: <a href="http://lists.llvm.org/pipermail/llvm-dev/2020-October/146182.html">http://lists.llvm.org/pipermail/llvm-dev/2020-October/146182.html</a></div><div>However there is not much I can do to address folks who object because "they don't see the interest" in it, this isn't a productive way of moving forward with such proposal IMO.</div><div> </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">
>> I guess it would make the lives of google employees easier?<br>
>><br>
> I explained before that Google internal integration flow is likely better<br>
> without this at the moment, TensorFlow itself is also in a reasonably good<br>
> spot at the moment. But Google is also not a monolithic place, some people<br>
> are working on small independent projects that they are open-sourcing, and<br>
> would like to be able to use LLVM.<br>
><br>
>>   Then what’s to stop every large org from committing their internal stuff<br>
> to master?<br>
><br>
><br>
><br>
> If their "internal stuff" is highly-coupled to LLVM, has zero-cost<br>
> maintenance on the community, and is something that multiple other parties<br>
> can benefit and established members of the community want to maintain and<br>
> collaborate on, why not?<br>
<br>
Let's be honest, nothing has "zero-cost".</blockquote><div><br></div><div>I hope you're not implying I'd be dishonest here right?</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"> It seems unhelpful to pretend it does. (FWIW, I explained a simple scenario that would make the bazel<br>
inclusion "costly" in my previous mail.)<br></blockquote><div><br></div><div>"zero-cost" is well defined: it is "as a community member: feel free to ignore, no one will bother you about it", and a subset of the community signed up for the maintenance. </div><div>I think it is also helpful to be concrete here: we have existing data and history with `gn`, it isn't hypothetical.</div><div><br></div><div><div>To be sure I address your previous email, that was about user expectations right? i.e. was it this part:</div><div><br></div><div>> people will assume we (=the LLVM community) maintain(s) a bazel build, which can certainly be a benefit but also a cost", e.g., when the build is not properly maintained, support is scarce, etc. and emails come in complaining about it (not thinking of prior examples here.)</div><div><br></div><div>Isn't this similar to the concerns from Renato here: <a href="http://lists.llvm.org/pipermail/llvm-dev/2020-October/146179.html">http://lists.llvm.org/pipermail/llvm-dev/2020-October/146179.html</a> ?</div></div><div>I acknowledge this as very valid concerns and offered some possibility to mitigate: <a href="http://lists.llvm.org/pipermail/llvm-dev/2020-October/146188.html">http://lists.llvm.org/pipermail/llvm-dev/2020-October/146188.html</a></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>
<br>
><br>
> I mentioned it before, but Bazel is not something internal or specific to<br>
> Google: it isn't (actually there are many incompatibilities between Bazel<br>
> and the internal system), 400 people attended the Bazel conference last<br>
> year. I attended this conference 3 years ago when I was at Tesla trying to<br>
> deploy Bazel internally. Many other companies are using Bazel, open-source<br>
> projects as well. Feel free to watch the talks online about SpaceX<br>
> <<a href="https://www.youtube.com/watch?v=t_3bckhV_YI" rel="noreferrer" target="_blank">https://www.youtube.com/watch?v=t_3bckhV_YI</a>> or Two Sigma and Uber<br>
> <<a href="https://www.youtube.com/watch?v=_bPyEbAyC0s" rel="noreferrer" target="_blank">https://www.youtube.com/watch?v=_bPyEbAyC0s</a>> for example<br>
<br>
Let's not conflate "using bazel" and "benefit for LLVM", the former<br>
is not up for debate here. (I mean, a lot of people use autoconf but<br>
we got rid of it anyway).<br></blockquote><div><br></div><div>I doubt we wouldn't have got rid of Autoconf if a chunk of the community offered to maintain it at "no cost" (again see definition).</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>
That said, I think the original question is highly relevant. As I also<br>
mentioned somewhere above, where do we draw the line is the key to this<br>
RFC at the end of the day. A lot of the arguments I hear pro integration<br>
apply to various other things that currently live out-of-tree, some of<br>
which were proposed and not integrated.</blockquote><div><br></div><div>Can you provide more concrete reference to these things that could have been integrated in similar "zero cost" fashion?</div><div>I'm all for consistency, and the only point of comparison here is `gn`.</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"> I think we should not dismiss<br>
this easily, no matter on which side of the argument you are this time.<br>
<br>
~ Johannes<br>
<br>
<br>
<br>
><br>
><br>
> I'm not trying to convince anyone to use Bazel, it has drawbacks, but the<br>
> point here is to recognize that this is about OpenSource communities that<br>
> Bazel is serving: these are users, some of us in the LLVM community are<br>
> trying to provide these users with a reasonably good integration story, and<br>
> we're ready to pay the cost for everyone.<br>
><br>
><br>
><br>
>><br>
>> *From:* Mehdi AMINI <<a href="mailto:joker.eph@gmail.com" target="_blank">joker.eph@gmail.com</a>><br>
>> *Sent:* Thursday, October 29, 2020 2:00 PM<br>
>> *To:* Chris Tetreault <<a href="mailto:ctetreau@quicinc.com" target="_blank">ctetreau@quicinc.com</a>><br>
>> *Cc:* Sterling Augustine <<a href="mailto:saugustine@google.com" target="_blank">saugustine@google.com</a>>; Mehdi Amini <<br>
>> <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 <<br>
>> <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<br>
>> <<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>
>> *Subject:* [EXT] Re: [llvm-dev] Contributing Bazel BUILD files similar to<br>
>> gn<br>
>><br>
>><br>
>><br>
>><br>
>><br>
>><br>
>><br>
>> On Thu, Oct 29, 2020 at 1:24 PM Chris Tetreault via llvm-dev <<br>
>> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
>><br>
>> The problem is that once it’s in community LLVM, it becomes the<br>
>> community’s problem.  The expectation is that individual contributors do<br>
>> not break anything in upstream.<br>
>><br>
>><br>
>><br>
>> I would expect that the community by now has concrete experience with `gn`<br>
>> gained over a few years demonstrating that this hasn't been a problem to<br>
>> have this in-tree, without a burden of support on the community.<br>
>><br>
>> In particular, I think that a salient point is the guarantee that no<br>
>> public bot would be testing it (I mean here by "no public bot" that no bot<br>
>> would email you when you break it).<br>
>><br>
>><br>
>><br>
>> Why else would you contribute it to the LLVM monorepo? If the goal is just<br>
>> to enable external-to-google orgs to collaborate on it, why not contribute<br>
>> it as a new repo separate from LLVM? You wouldn’t need to ask anybody’s<br>
>> permission to do this.<br>
>><br>
>><br>
>><br>
>> Yes, we could do this, and you are correct that in many cases a motivation<br>
>> to upstream a component is to make sure it is maintained by the community<br>
>> and works out of the box.<br>
>><br>
>> In this case it is slightly different: we are OK with people to break<br>
>> this. We are already maintaining these files out-of-tree for our own<br>
>> purposes, and this has been the case for years as Sterling mentions. I<br>
>> would even suspect that for Google internal build integration, it is<br>
>> actually easier to have these files internal only rather than unsupported<br>
>> upstream.<br>
>><br>
>> So why are we doing it? I mentioned this in another answer: this is mainly<br>
>> to provide a collaboration space for the support of OSS projects using<br>
>> Bazel interested to use LLVM (and some subprojects).<br>
>><br>
>> Having them in-tree means that we can publish every day (or more) a git<br>
>> hash that we validate with Bazel on private bots (like `gn`) and every<br>
>> project can use to clone the LLVM monorepo and integrate in their build<br>
>> flow easily. Another repo, submodules, etc. are not making this possible /<br>
>> practical.<br>
>><br>
>><br>
>><br>
>><br>
>><br>
>><br>
>><br>
>><br>
>><br>
>> *From:* Sterling Augustine <<a href="mailto:saugustine@google.com" target="_blank">saugustine@google.com</a>><br>
>> *Sent:* Thursday, October 29, 2020 1:14 PM<br>
>> *To:* Chris Tetreault <<a href="mailto:ctetreau@quicinc.com" target="_blank">ctetreau@quicinc.com</a>><br>
>> *Cc:* 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<br>
>> <<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 <<br>
>> <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<br>
>> <<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>
>> *Subject:* [EXT] Re: [llvm-dev] Contributing Bazel BUILD files similar to<br>
>> gn<br>
>><br>
>><br>
>><br>
>> On Thu, Oct 29, 2020 at 12:29 PM Chris Tetreault via llvm-dev <<br>
>> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
>><br>
>> I think Renato has articulated quite well some concerns I have about this<br>
>> but was unable to express. I would very much prefer if we just focus on<br>
>> using CMake effectively.<br>
>><br>
>> ...<br>
>><br>
>> For example, when trying to implement the same logic on both will not be<br>
>> trivial. So, whenever we want to add some functionality or improve how we<br>
>> build LLVM with one system, we'll have to do so in multiple build systems<br>
>> that do not easily match each other.<br>
>><br>
>><br>
>><br>
>> Google already does all of this work, and has for years. I think it is<br>
>> fair to say that it hasn't been a burden on the community.<br>
>><br>
>><br>
>><br>
>> If we don't try to match functionality, we'll segregate the community,<br>
>> because people will be able to do X on build system A but not B, and the<br>
>> similar features cluster together and then we have essentially two projects<br>
>> built from the same source code.<br>
>><br>
>><br>
>><br>
>> As long as we keep CMake as the canonical system everything will be fine.<br>
>> It works perfectly well today, except that not everyone gets to see or use<br>
>> the bazel files. They exist right now; they work right now; and it hasn't<br>
>> been a burden on anyone but the people who care about bazel.<br>
>><br>
>><br>
>><br>
>> Testing this, or worse, trying to fix a buildbot that is built with Bazel<br>
>> (and having to install Java JDK and all its dependencies) on potentially a<br>
>> hardware that you do not have access to, will be a nightmare to debug. The<br>
>> nature of post-commit testing, revert and review of LLVM will not make that<br>
>> simpler. Unless we treat the Bazel build as "not our problem" (which<br>
>> defeats the point of having it?).<br>
>><br>
>><br>
>><br>
>> Google makes it work like this today, with the rest of the project<br>
>> treating it as "not our problem" because they don't even see that they<br>
>> exist. The build bot issues would be real, but I think surmountable, given<br>
>> that Google already cleans up the bazel files, it just doesn't push them.<br>
>> Perhaps an explicit policy that cmake folks don't have to update the bazel<br>
>> files would be helpful.<br>
>><br>
>><br>
>><br>
>> To make matters worse, our CMake files are not simple, and do not do all<br>
>> of the things we want them to do in the way we understand completely. There<br>
>> is a lot of kludge that we carry and with that comes in two categories: the<br>
>> things that we hate and would love to fix, and the things that are fixes<br>
>> that we have no idea are there. The former are the reasons why people want<br>
>> to start a new build system, the latter is why they soon realise that was a<br>
>> mistake (insert XKCD joke here).<br>
>><br>
>><br>
>><br>
>> It wouldn't be starting a new build system, it would be making a<br>
>> pre-existing, already extremely well functioning one, available to more<br>
>> people.<br>
>><br>
>><br>
>><br>
>> I can definitely see folks who use cmake not wanting more hassle--that may<br>
>> be a valid reason not to do it. But "it won't work" or "it's hard to keep<br>
>> up" or "it's too complicated" seem well refuted by a multi-year existence<br>
>> proof.<br>
>><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><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>
> _______________________________________________<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" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div></div></div></div></div></div></div></div>