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

On 28 Jul 2016 8:36 a.m., "David Chisnall via llvm-dev" <
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.

My tuppence.

Cheers,
Renato
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160728/e0222547/attachment.html>

On 28 Jul 2016, at 08:59, Renato Golin <renato.golin at linaro.org>
wrote:
> 
> On 28 Jul 2016 8:36 a.m., "David Chisnall via llvm-dev"
<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.
I think it’s important to differentiate between ‘needs’ as in ‘requires a
precisely matched version’ and ‘needs’ as in ‘requires something to provide this
functionality’.  Clang needs something equivalent to libc++ and something
equivalent to libunwind, but it doesn’t (or, at least, shouldn’t) need a
specific version of LLVM’s implementations of these.  In contrast, clang needs a
bunch of LLVM libraries and depends on precise versions.

In FreeBSD, we used to ship libsupc++, libstdc++ and GCC’s libunwind.  We then
switched to shipping libcxxrt, libstdc++, and GCC’s libunwind, then to shipping
libcxxrt, libc++, and GCC’s libunwind, and are now switching to shipping
libcxxrt, libc++, and LLVM’s libunwind.  We build all of these with clang and
gcc.  When we import a new lldb and clang (and, soon, when we start to import
lld), we need to do a complete import of LLVM, clang, lld, and lldb at the same
time, or things will break.  We can update libunwind and libc++ on a different
schedule.  We’ll probably want to keep roughly the same versions of these for an
entire major release series (modulo bug fixes) for stability and we will want a
new clang, lld, and lldb to work with the old ones.

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/20160728/09b5ed23/attachment.bin>

On 28 July 2016 at 09:42, David Chisnall <david.chisnall at cl.cam.ac.uk>
wrote:
> I think it’s important to differentiate between ‘needs’ as in ‘requires a
precisely matched version’ and ‘needs’ as in ‘requires something to provide this
functionality’.  Clang needs something equivalent to libc++ and something
equivalent to libunwind, but it doesn’t (or, at least, shouldn’t) need a
specific version of LLVM’s implementations of these.  In contrast, clang needs a
bunch of LLVM libraries and depends on precise versions.
Absolutely!

> In FreeBSD, we used to ship libsupc++, libstdc++ and GCC’s libunwind.  We
then switched to shipping libcxxrt, libstdc++, and GCC’s libunwind, then to
shipping libcxxrt, libc++, and GCC’s libunwind, and are now switching to
shipping libcxxrt, libc++, and LLVM’s libunwind.  We build all of these with
clang and gcc.  When we import a new lldb and clang (and, soon, when we start to
import lld), we need to do a complete import of LLVM, clang, lld, and lldb at
the same time, or things will break.  We can update libunwind and libc++ on a
different schedule.  We’ll probably want to keep roughly the same versions of
these for an entire major release series (modulo bug fixes) for stability and we
will want a new clang, lld, and lldb to work with the old ones.
My problem, and I'll be quick not to digress too much, is that
--rtlib=compiler-rt is slightly broken. I can't assume libunwind or
libc++abi are there, so for rtlib=RT, I don't add -lunwind and
-lc++abi "as needed" like we do for libgcc's counterparts.

This breaks expectations more than implementations. To use compiler-rt
I need to also add -lgcc_s or -lunwind, and that's not obvious. A
warning here would be weird.

Again, I totally agree it's not a hard requirement, nor version locked
or anything, but it would be good to "assume" the'd be there for
the
*default* case, and let people mix and match by using other advanced
flags.

cheers,
--renato

> On Jul 28, 2016, at 1:42 AM, David Chisnall via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> On 28 Jul 2016, at 08:59, Renato Golin <renato.golin at linaro.org>
wrote:
>> 
>> On 28 Jul 2016 8:36 a.m., "David Chisnall via llvm-dev"
<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.
> 
> I think it’s important to differentiate between ‘needs’ as in ‘requires a
precisely matched version’ and ‘needs’ as in ‘requires something to provide this
functionality’.  Clang needs something equivalent to libc++ and something
equivalent to libunwind, but it doesn’t (or, at least, shouldn’t) need a
specific version of LLVM’s implementations of these.  In contrast, clang needs a
bunch of LLVM libraries and depends on precise versions.
> 
> In FreeBSD, we used to ship libsupc++, libstdc++ and GCC’s libunwind.  We
then switched to shipping libcxxrt, libstdc++, and GCC’s libunwind, then to
shipping libcxxrt, libc++, and GCC’s libunwind, and are now switching to
shipping libcxxrt, libc++, and LLVM’s libunwind.  We build all of these with
clang and gcc.  When we import a new lldb and clang (and, soon, when we start to
import lld), we need to do a complete import of LLVM, clang, lld, and lldb at
the same time, or things will break.  We can update libunwind and libc++ on a
different schedule.  We’ll probably want to keep roughly the same versions of
these for an entire major release series (modulo bug fixes) for stability and we
will want a new clang, lld, and lldb to work with the old ones.
Aren’t downstream integrator like FreeBSD the right target to the individual
read-only git repo? I.e. if you don’t need to commit (git push) directly,
"git clone http://llvm.org/git/libcxx.git
<http://llvm.org/git/libcxx.git>” and "git clone
http://llvm.org/git/libcxxabi.git <http://llvm.org/git/libcxxabi.git>”
should be fine?


— 
Mehdi

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