[llvm-dev] [Incubation] Request to incubate mlir-npcomp

[Nicolai Hähnle via llvm-dev]

On Wed, Jun 24, 2020 at 8:16 PM Sean Silva <silvasean at google.com> wrote:
> On Wed, Jun 24, 2020 at 9:54 AM Nicolai Hähnle <nhaehnle at gmail.com> wrote:
>> On Tue, Jun 23, 2020 at 2:40 PM Stella Laurenzo via llvm-dev
>> <llvm-dev at lists.llvm.org> wrote:
>> > 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).
>>
>> How do you deal with the problem of using the "right" LLVM version? As
>> somebody who spends a significant amount of time on a project that is
>> open-source but out-of-tree -- and for good reasons that mean we're
>> unlikely to want to incubate in this fashion -- I find this to be a
>> major problem.
>>
>> If the goal of incubation is to eventually become part of the
>> llvm-project monorepo, I feel that being inside the monorepo should be
>> a goal early on.
>
>
> Actually that would be a big problem in practice, because it means that either:
> 1. random changes in the monorepo can put the incubator into an unbuildable state
> 2. people changing the monorepo need to somehow build and test and fix incubator projects

I think you misunderstood. The idea isn't to have the incubated
project in github.com/llvm/llvm-project. It's that the incubator
project is a _fork_ of llvm-project.


> 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.

I suppose this works, though it seems to me that this is strictly less
convenient than having the project be a fork and just merging the
llvm-project master periodically instead of changing the README and
forcing everybody to update their llvm-project checkout associated to
the project manually.


On Wed, Jun 24, 2020 at 7:36 PM Mehdi AMINI <joker.eph at gmail.com> wrote:
> 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?)

The point of incubation is to have a path for getting into
llvm-project, right? At which point you have that flexibility, but we
don't give out that flexibility immediately as a free-for-all. Having
the incubated project be an llvm-project fork gives you the "training
wheels" for working in a way where you consider co-development of both
the incubated project and core LLVM. I agree that there'd need to be
guidelines about keeping the "local" changes to the code from
llvm-project small.

Really, my main motivation for this though is to make day-to-day
development simpler for the incubated project as per my replies above
:)

Cheers,
Nicolai


-- 
Lerne, wie die Welt wirklich ist,
aber vergiss niemals, wie sie sein sollte.