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

Renato Golin via llvm-dev llvm-dev at lists.llvm.org
Thu Jul 21 10:11:18 PDT 2016

On 21 July 2016 at 18:06, David Chisnall <david.chisnall at cl.cam.ac.uk> wrote:
> - libc++ is useful and frequently built without any of the rest of LLVM

but it interlocks with libunwind and compiler-rt...

> The same applies to libunwind.  If you’re building an entire toolchain then you might want to use it, but most projects don’t benefit from it and it implements a well-defined standard ABI and so doesn’t need to be updated in lockstep with anything else.

Using RT without libunwind on ARM is weird. libgcc_s has some of the
functionality, but the split between libgcc, _s and _eh is not the
same as compiler-rt, libc++abi and libunwind.

If one want's a reasonable solution, one (today) needs to include all
three. Then why not libc++? I mean, GCC does build libstdc++ in tree
already, so it wouldn't be unheard of.

> clang-tools-extra is explicitly a bunch of stuff that doesn’t belong in the main clang repo because it’s not of interest to most people doing clang work, so it’s hard to see why it would be of interest to everyone doing LLVM work.  Additionally, I believe that they’re mostly things that are built on top of APIs in clang that are supposed to be moderately stable, so shouldn’t need atomically updating with respect to clang very often.

ok, no strong feelings about it.

> Compiler-rt probably makes sense if clang is there, as it includes a lot of the run-time support for clang.

RT strongly fits into the core. If there a minimal-minimal core to be
set, that'd be { llvm, clang, RT }. If not for what it can do today,
for what it should do in the future.


More information about the llvm-dev mailing list