<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 10:30 PM Johannes Doerfert via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I replied only selectively.<br>
<br></blockquote><div><br></div><div>:)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><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>
<br></blockquote><div><br></div><div>To be fair the build system maintainer at the time (me) didn't want to maintain autoconf anymore especially when we had cmake and no one wanted to step forward to maintain it. :)</div><div><br></div><div>-eric</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
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. I think we should not dismiss<br>
this easily, no matter on which side of the argument you are this time.<br>
<br></blockquote><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
~ 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>
_______________________________________________<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>