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

[Stella Laurenzo via llvm-dev]

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>