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

On 21 Jul 2016, at 17:49, Renato Golin <renato.golin at linaro.org>
wrote:
> 
> As a back-of-the-envelope, I suggest: llvm, clang, clang-tools-extra,
> compiler-rt, libc++, libc++abi, libunwind, test-suite.
The minimum that makes sense is llvm, though that defeats the point of a
combined repo.

I don’t think that libc++ / libc++abi make sense there for several reasons:

- You very rarely need to update them in lockstep with anything else

- LLVM/Clang is useful and frequently built without libc++

- libc++ is useful and frequently built without any of the rest of LLVM

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.

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.

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

David

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3719 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160721/ac9a4787/attachment.bin>

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.

cheers,
--renato

On Fri, Jul 22, 2016 at 1:11 AM, Renato Golin via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> 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.
Not true - the non-gnu libunwind which is outside of the llvm family
of projects works just fine on AArch64. We're dealing with hopefully
standard interfaces and A1 vs A2 comparisons.

Again - this is thread is digressing - wrong solution to wrong problem
- Renato step back and try not to let the thread get detracted