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

> On Jun 24, 2020, at 9:53 AM, Nicolai Hähnle via llvm-dev <llvm-dev at
lists.llvm.org> 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.

I’m contributing to an external project based on MLIR (which should become
public soon).  That project is using the LLVM monorepo as a git submodule,
allowing us to update it and track at project-specific times.  It seems to work
well.

-Chris

On Tue, Jun 30, 2020 at 12:54 PM Chris Lattner <clattner at nondot.org>
wrote:
>
>
> > On Jun 24, 2020, at 9:53 AM, Nicolai Hähnle via llvm-dev <
> llvm-dev at lists.llvm.org> 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.
>
>
> I’m contributing to an external project based on MLIR (which should become
> public soon).  That project is using the LLVM monorepo as a git submodule,
> allowing us to update it and track at project-specific times.  It seems to
> work well.
>
The only problem I've had with that approach (other than the well-known
usability issues of git submodules in general) is when you end up with more
complicated dependency structures that bottom out on LLVM. In these diamond
scenarios, it is really easy to end up with a ton of LLVM repo clones on
your workstation. In general, though, I do prefer the simplicity of clone,
submodule init/update and build.

>
> -Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200630/f2fd40a8/attachment.html>

> On Jun 30, 2020, at 12:59 PM, Stella Laurenzo <stellaraccident at
gmail.com> wrote:
> 
> 
> I’m contributing to an external project based on MLIR (which should become
public soon).  That project is using the LLVM monorepo as a git submodule,
allowing us to update it and track at project-specific times.  It seems to work
well.
> 
> The only problem I've had with that approach (other than the well-known
usability issues of git submodules in general) is when you end up with more
complicated dependency structures that bottom out on LLVM. In these diamond
scenarios, it is really easy to end up with a ton of LLVM repo clones on your
workstation. In general, though, I do prefer the simplicity of clone, submodule
init/update and build.
Sure - no doubt.  I’m not a fan of submodules either in practice, but having one
that you manage seems to be working ok.  It is just a balance between all the
other suboptimal answers to this problem.

-Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200630/1ebe370b/attachment.html>