[llvm-dev] MLIR landing in the monorepo
Mehdi AMINI via llvm-dev
llvm-dev at lists.llvm.org
Fri Nov 15 11:56:38 PST 2019
On Fri, Nov 15, 2019 at 11:43 AM Fāng-ruì Sòng <maskray at google.com> wrote:
> On Fri, Nov 15, 2019 at 11:15 AM Mehdi AMINI <joker.eph at gmail.com> wrote:
> > On Fri, Nov 15, 2019 at 10:58 AM Fāng-ruì Sòng <maskray at google.com>
> >> Since you are going to rewrite the mlir history anyway, you can
> >> probably delete accidentally checked in large files if any.
> > Good point, I checked and this is the largest file in the history of the
> repo as far as I can tell:
> >> * I don't know whether the file CONTRIBUTING.md is still appropriate,
> >> at least for the Code of Conduct, LLVM has its own version.
> >> * g3doc/ seems a very Google specific name. Does `docs/` work?
> >> * bindings/python/pybind.cpp - does it have to be an in-tree plugin?
> >> * The Apache 2 license headers are verbose. LLVM uses
> >> SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception.
> > Absolutely! All of these points (except the python bindings) are on my
> TODO list of things to do at the time of the merge. At the moment there is
> just a script continuously performing the merge in my test repository so
> this is an exact view of the current state of the public repo.
> > I could also try to rewrite the license in the header in all the history
> of the repository, but I'm not sure it won't be brittle in practice, I was
> planning to do an update to all the files before pushing.
> > I'll send the final version of the repo next month, I can CC you if
> you'd like to review this before we push it?
> > For the python bindings, these are intended to provide some equivalent
> facility to the LLVM python bindings:
> ; while they need some work at the moment, I think we will want to have
> bindings though.
> Another thing is that after you make CMake work
> -DLLVM_ENABLE_PROJECTS='...;mlir;...', it'd be nice to reorder that
> commit to the very beginning of the MLIR history. People want to
> bisect and build at any commit in the pre-monorepo history. If they
> can only build at the last commit, that will still be very
I don’t think it is possible: it requires changes in LLVM itself but also
the revision pre-merge contain *only* MLIR and not LLVM: these revision
won’t build as is.
I think bisection in the pre-merge history will have to use “commit date”
to find a compatible revision in LLVM, and at this point the need for the
more verbose syntax I send earlier isn’t the more annoying part.
Hopefully going back far in time is not something that will be common.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev