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

[Chris Bieneman via llvm-dev]

> On Jul 28, 2016, at 12:59 AM, Renato Golin via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> On 28 Jul 2016 8:36 a.m., "David Chisnall via llvm-dev" <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
> > This does not apply to libc++.  We support building the entire LLVM suite with other C++ standard library implementations (at least libstdc++, and I think also with Visual Studio’s implementation), so there is no dependency of anything on libc++.  Similarly, we support building libc++ with other compilers (in FreeBSD, we currently build it with gcc 6.1 for RISC-V, for example, where the LLVM toolchain is not quite useable).
> >
> > The same applies to libunwind, to an even greater degree (where libc++ implements a standard API, libunwind implements a standard ABI).
> 
> I think the dependencies of lib* in LLVM are more conceptual than version lock, but they're still there.
> 
> I agree with you in all other points, mind you, but RT needs an unwind library as much as it needs clang. Without them, RT "can" (and indeed does) work, but we're not providing a complete solution.
> 
> I won't *push* to bundle libunwind, libcxxabi (and ultimately libcxx) on those merits alone, but my opinion is that we should. I can't see much use in RT without them. That's why we're still defaulting to libgcc on Linux.
> 
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.

For example, the Compiler-RT sanitizers are used with GCC and libgcc. They can be built to be used with libstdc++ as well as libc++ (although I do think that loses some features).

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.

As a straw man I would suggest the following criteria for inclusion into the mono-repo:

(1) Projects in the mono-repo must be tightly coupled to specific versions or commits of other projects in the mono-repo
(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
(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.

Thoughts?

-Chris

> My tuppence.
> 
> Cheers, 
> Renato
> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160728/39c2bb92/attachment.html>