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

[Mehdi Amini via llvm-dev]

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