<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jun 25, 2020 at 8:27 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:1px solid rgb(204,204,204);padding-left:1ex">On Wed, Jun 24, 2020 at 8:16 PM Sean Silva <<a href="mailto:silvasean@google.com" target="_blank">silvasean@google.com</a>> wrote:<br>
> On Wed, Jun 24, 2020 at 9:54 AM Nicolai Hähnle <<a href="mailto:nhaehnle@gmail.com" target="_blank">nhaehnle@gmail.com</a>> wrote:<br>
>> 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.<br>
><br>
><br>
> Actually that would be a big problem in practice, because it means that either:<br>
> 1. random changes in the monorepo can put the incubator into an unbuildable state<br>
> 2. people changing the monorepo need to somehow build and test and fix incubator projects<br>
<br>
I think you misunderstood. The idea isn't to have the incubated<br>
project in <a href="http://github.com/llvm/llvm-project" rel="noreferrer" target="_blank">github.com/llvm/llvm-project</a>. It's that the incubator<br>
project is a _fork_ of llvm-project.<br>
<br>
<br>
> Currently, in npcomp, we have a monorepo hash that we bump periodically. That means that people can follow our README and build our project at any point by checking out the right monorepo revision. Npcomp developers have the responsibility of fixing our own code as LLVM updates.<br>
<br>
I suppose this works, though it seems to me that this is strictly less<br>
convenient than having the project be a fork and just merging the<br>
llvm-project master periodically instead of changing the README and<br>
forcing everybody to update their llvm-project checkout associated to<br>
the project manually.<br><br></blockquote><div><br></div><div>I think the main consideration here should be what happens when it becomes time to integrate into LLVM.</div><div>There are several possibilities:</div><div>1) do a merge commit, preserving the history correctly, including any modifications to LLVM.  This is probably not a good idea because: 1) we suddenly get lots of non-linear history and 2) the modifications to LLVM over time probably need to get reviewed.  This is only really possible with a 'fork'  </div><div>2) Use branch rewriting like MLIR/Flang.  This keeps the commit history of the incubator, but loses the ability to bisect the incubator before the merge.  This is only really possible if things start out of tree.</div><div>3) Squash the history of the incubator and apply it as a single commit.  This obviously loses the history.  This is probably possible developing as a fork or out of tree, but might require a significantly large integration patch.  It can also be used to consolidate changes to LLVM, but those would still require review which might be difficult.</div><div><br></div><div>Generally, I think #2 has been a reasonably successful model.  MLIR did not store a hash, but attempted to stay at head, which made it somewhat more difficult to keep up with the pace of development.  I would recommend working out of tree for most incubated projects and encourage teams to push modifications to the LLVM core upstream early rather than later.</div><div><br></div><div>Steve</div></div></div>