<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jun 24, 2020 at 9:54 AM Nicolai Hähnle 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-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">On Tue, Jun 23, 2020 at 2:40 PM Stella Laurenzo via llvm-dev<br>
<<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
> We originally started it as a fork of the LLVM repository, but transitioned to the MLIR standalone template, and we found it more productive to iterate out of tree in this fashion, bumping to the latest LLVM version every week or so as needed (note: the ability to exist out of tree for MLIR dependent projects is actually quite good, and the more of us who do it, the better it becomes).<br>
<br>
How do you deal with the problem of using the "right" LLVM version? As<br>
somebody who spends a significant amount of time on a project that is<br>
open-source but out-of-tree -- and for good reasons that mean we're<br>
unlikely to want to incubate in this fashion -- I find this to be a<br>
major problem.<br>
<br>
If the goal of incubation is to eventually become part of the<br>
llvm-project monorepo, I feel that being inside the monorepo should be<br>
a goal early on. This would make your project more inclusive, as<br>
others will automatically have the right LLVM version -- they don't<br>
have to follow some syncing mechanism that you may have tooling for<br>
inside of Google but which isn't available outside. </blockquote><div><br></div><div>There is nothing specific to Google, quite the opposite actually: the "update once a week" here is purely OSS and does not work inside Google.</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">You can always<br>
"bump to the latest LLVM version every week or so" by doing a merge<br>
commit.<br></blockquote><div><br></div><div>I'm not sure I perceive how having code that is a "read-only" mirror (the LLVM monorepo) mixed within the project repo would be helping to be "more inclusive"?</div><div>Not duplicating the monorepo helps to ensure that you don't diverge from the rest of LLVM by patching it (you're losing flexibility in the development of course, but then shouldn't this just be in the monorepo in the first place?)</div><div><br></div><div>But it also seems to me that we're spreading the discussion on the "right template" between the incubator thread and this particular proposal, which does not help to keep track.</div><div><br></div><div>-- </div><div>Mehdi</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>
Cheers,<br>
Nicolai<br>
<br>
<br>
-- <br>
Lerne, wie die Welt wirklich ist,<br>
aber vergiss niemals, wie sie sein sollte.<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>