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

> On 21 July 2016 at 18:12, Justin Lebar <jlebar at google.com> wrote:
> >   llvm, clang, clang-tools-extra, lld, polly, lldb, llgo, compiler-rt,
> > openmp, and parallel-libs.
> 
> I really, *really* would like to see libc++ / abi / unwind. :)
> 
> My reason is that, when building toolchains, the C++ ABI and unwinding
> are fundamental parts of the run-time library, of which RT is only
> part of.
When building *your* toolchain...

My toolchain uses clang but not libc++/abi/unwind, we have our own, and
we don't currently include them in our tree.  We do include compiler-rt.

If we should change our minds later we can opt-in to anything else we
want (libcxx etc, lld? lldb? who knows) but in the meantime they are
unnecessary baggage for my purposes.

--paulr

On 21 July 2016 at 22:33, Robinson, Paul <paul.robinson at sony.com>
wrote:
> When building *your* toolchain...
I know... :)

> If we should change our minds later we can opt-in to anything else we
> want (libcxx etc, lld? lldb? who knows) but in the meantime they are
> unnecessary baggage for my purposes.
I really see no way of doing this without bikeshedding, other than do
what Mehdi suggested and put all non-dying projects.

Cloning the first repo could be bad, especially for some of our
boards, so I won't propose it myself. Setting up NFS is rarely an
option (support, stability), so we will suffer for including lld,
lldb, etc. I'd prefer to see them out.

Since I'm not the one trying to reach consensus in this thread, I'll
just state what would be best for me and let Justin collect the
opinions. :)

I'm honestly fine with whatever decision, as we can usually work
around the problems, and it's probably cheaper than to bikeshed to
death.

cheers,
--renato

> On Jul 21, 2016, at 2:33 PM, Robinson, Paul via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
>> On 21 July 2016 at 18:12, Justin Lebar <jlebar at google.com>
wrote:
>>>  llvm, clang, clang-tools-extra, lld, polly, lldb, llgo,
compiler-rt,
>>> openmp, and parallel-libs.
>> 
>> I really, *really* would like to see libc++ / abi / unwind. :)
>> 
>> My reason is that, when building toolchains, the C++ ABI and unwinding
>> are fundamental parts of the run-time library, of which RT is only
>> part of.
> 
> When building *your* toolchain...
> 
> My toolchain uses clang but not libc++/abi/unwind, we have our own, and
> we don't currently include them in our tree.  We do include
compiler-rt.
> 
> If we should change our minds later we can opt-in to anything else we
> want (libcxx etc, lld? lldb? who knows) but in the meantime they are
> unnecessary baggage for my purposes.
As a developer, you can checkout part of the repo with sparse-checkout.
As a downstream integrator, you can filter out the repo history as you want
before merging into your repo.

— 
Mehdi

> -----Original Message-----
> From: mehdi.amini at apple.com [mailto:mehdi.amini at apple.com]
> Sent: Thursday, July 21, 2016 3:16 PM
> To: Robinson, Paul
> Cc: Renato Golin; Justin Lebar; llvm-dev at lists.llvm.org
> Subject: Re: [llvm-dev] [RFC] One or many git repositories?
> 
> 
> > On Jul 21, 2016, at 2:33 PM, Robinson, Paul via llvm-dev <llvm-
> dev at lists.llvm.org> wrote:
> >
> >> On 21 July 2016 at 18:12, Justin Lebar <jlebar at
google.com> wrote:
> >>>  llvm, clang, clang-tools-extra, lld, polly, lldb, llgo,
compiler-rt,
> >>> openmp, and parallel-libs.
> >>
> >> I really, *really* would like to see libc++ / abi / unwind. :)
> >>
> >> My reason is that, when building toolchains, the C++ ABI and
unwinding
> >> are fundamental parts of the run-time library, of which RT is only
> >> part of.
> >
> > When building *your* toolchain...
> >
> > My toolchain uses clang but not libc++/abi/unwind, we have our own,
and
> > we don't currently include them in our tree.  We do include
compiler-rt.
> >
> > If we should change our minds later we can opt-in to anything else we
> > want (libcxx etc, lld? lldb? who knows) but in the meantime they are
> > unnecessary baggage for my purposes.
> 
> As a developer, you can checkout part of the repo with sparse-checkout.
I'm not clear why imposing this cost on everybody who wants less-than-all
(which I'd think would be most people) is superior to the submodule thing
which can be maintained centrally by people who actually understand how to 
do it.
> As a downstream integrator, you can filter out the repo history as you
> want before merging into your repo.
Hmmm maybe, maybe not.  It sounds like the claim is: you can do a sparse
checkout of upstream, then merge it to a different branch, and get only 
the history of the stuff that was sparsely checked out.  Does this work 
with subtree merges?  Our branches are not rooted at the 'llvm'
directory,
and I am suspicious about what the sparse checkout config would do to the 
local branch.  (I know, I should do the experiment myself, but right now 
I'm in the middle of a release-prep circus and really shouldn't be 
spending the time to write this email:-).)

If all of this magic *does* work, then mainly it's a matter of scripting
the sparse-checkout config and deploying that internally.  Not free, but
maybe not horrible either.
--paulr
> 
> —
> Mehdi
>