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

Chris Bieneman via llvm-dev
2016-07-28T17:21:44Z

> 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>