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

> Which projects do we put under this monolithic repository?
The proposal at the moment is to include

  llvm, clang, clang-tools-extra, lld, polly, lldb, llgo, compiler-rt,
openmp, and parallel-libs.

This is the set {llvm} plus the transitive closure of "projects that
are version-locked to a project in the set", where the closure is
taken over the set of all active LLVM subprojects.

Projects that don't depend on a specific version of llvm or some other
subproject -- test-suite and libc++ -- are not included.  Everything
else is, because the whole idea is to have one repository that
captures the implicit versioning dependencies between (say) lldb and
llvm.

As soon as we have one version-locked subproject that's not in the
monolithic repo, we now we have to maintain an umbrella repo that
tells you which version of llvm corresponds to which version of the
version-locked-but-not-in-monolithic repo.

The cost of including additional projects in the monolithic repository
is very low, since you can ignore them using sparse checkouts.

On Thu, Jul 21, 2016 at 9:49 AM, Renato Golin <renato.golin at linaro.org>
wrote:
> Question:
>
> Which projects do we put under this monolithic repository?
>
> SVN has about 42 projects, some of them dead, some of them in life support.
>
> So far, being "an upstream repository" meant being inside the
LLVM SVN
> server. We'll change that to "being inside the monolithic LLVM
> repository". But this can become huge, and not all projects
"ink" back
> to LLVM.
>
> An alternative would be to just have some core projects in the
> monolithic and everything else as separate, but then what's core?
>
> As a back-of-the-envelope, I suggest: llvm, clang, clang-tools-extra,
> compiler-rt, libc++, libc++abi, libunwind, test-suite.
>
> I'm thinking LLD and LLDB could remain out, but I don't think it
would
> be too weird for them to be in...
>
> Anything else? Less?
>
> cheers,
> --renato

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.

RT has the builtins (and a lot of other stuff), but it can't unwind on
its own. So debuggers (LLDB), profilers (which lives in RT) and basic
stack traces don't work, unless you use an alternative option (like
libgcc). This is *specially* true for ARM.

When unwinding C++ code, one needs cxa_* functions, and that's in
libc++abi, which interoperates with libc++, unwind and RT.

The LLVM triple abi/unwind/RT is not divided in the same way as
gcc_eh/gcc_s/gcc, so picking some but not others is not a sane option.
Plus, validating every possible choices needs one buildbot for each
combination, which is not feasible, at least not for us.

Basically, picking RT and not unwind/abi breaks their
inter-dependencies, so does picking abi but not libc++.

> Projects that don't depend on a specific version of llvm or some other
> subproject -- test-suite and libc++ -- are not included.  Everything
> else is, because the whole idea is to have one repository that
> captures the implicit versioning dependencies between (say) lldb and
> llvm.
I'm fine with the test-suite not being in the core, but the others
will make it very hard to build actual toolchains.

They're also reasonably small, rarely updated and self-contained, so I
don't see why they can't be there.

cheers,
--renato

On Thu, Jul 21, 2016 at 1:55 PM Renato Golin 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. :)
>
FWIW, I agree for all the reasons you outline.

I didn't suggest it to Justin only because I know those in particular
aren't really version-locked. Personally, I'd rather merge all of it and
make checking out a slice easy and simple. But I felt like the decision
there could be separate for those libraries, and probably should be made by
the devs working on those libraries more than me.

-Chandler
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160721/fc5d59a2/attachment.html>

> 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