[llvm-dev] [RFC] One or many git repositories?

[Renato Golin via llvm-dev]

On 28 July 2016 at 18:21, Chris Bieneman <beanz at apple.com> wrote:
> Renato, I just want to point out that the Compiler-RT story is *WAY* more
> complicated than it might seem from your comments here. Compiler-RT is
> really two or three conceptually different things that happen to be in the
> same project, and parts of it are very useful without libunwind, libcxxabi,
> and libcxx.

Indeed! I didn't seem to imply that was the *only* use. Just *my* main use. :)


> I would not object to a mono-repo that included LLVM, Clang, LLD, and
> Clang-Tools-Extra. I strongly object to any mono-repo that includes any of
> the runtime library projects. I also think that once you move away from the
> “mono-repo including all” you need to identify criteria for how you
> determine which projects get included, and potentially how you evaluate
> adding projects to the mono-repo.

I agree.

I'd much prefer a mono repo that *doesn't* have RT than one that does
have it, but not libunwind/c++abi.

Some proposals said RT would be in, unwind/c++ would be out, and
that's what I found confusing.


> (1) Projects in the mono-repo must be tightly coupled to specific versions
> or commits of other projects in the mono-repo

Yup. That's the hard line we cannot cross. LLVM and Clang are
obviously in that group. Extra, RT and LLD, are fuzzy. Others are a
lot less fuzzy (in relation to LLVM only).

Parts of RT (usage) are heavily associated with libunwind and
libc++abi, and their alternatives don't all have the same cut, so
mixing and matching them is complicated. But that's orthogonal to the
monorepo decisions, and it can very well be bundled again or unbundled
even more. This one is for a future discussion.


> (2) The projects in the mono-repo most provide wide benefit to the community
> such that the overall community benefit outweighs the impacts of the project
> being in the repo

Yup. I (personally) think RT's builtins should fulfill that role, as
LLVM back-ends depend on the run-time library to work, but not in its
current (disorganised) form.


> (3) Projects in the mono-repo must conform to some defined set of standards.
> LLVM’s coding standards might be a bit much, but something along those
> lines.

I'd say all projects in the LLVM official project should conform to
the coding standards and developer policies, inside or outside of the
monorepo.

I think the different between being in the monorepo or not is more
practical and logical than social.

cheers,
--renato