[llvm-dev] Add more projects into Git monorepo

[David Chisnall via llvm-dev]

On 8 May 2017, at 20:51, Mehdi AMINI <joker.eph at gmail.com> wrote:
> 
> 
> 2017-05-07 1:01 GMT-07:00 David Chisnall via llvm-dev <llvm-dev at lists.llvm.org>:
> Is this intended to be the monorepo that eventually becomes the official repo, because if so I strongly object to putting libunwind, libc++ and libc++abi in it.  I have recently been working on bring-up for libc++ and libunwind on a new platform and the integration of libunwind with the LLVM build system is already annoying (you can’t build it unless you have a working C++ standard library implementation for your target, even thought it’s a dependency for libc++), having to have a complete LLVM checkout would be even more overhead.
> 
> Please clarify the overhead.

My clone of libunwind is around 4MB.  A clone of LLVM is 2-3 orders of magnitude bigger.  The clone on my local system doesn’t matter too much (though it would be an annoying waste), because I have spare disk space, but each project, once it’s working, also gets cloned to our CI system, which is always short on disk space because it archives build artefacts.  Network bandwidth is also an issue.

There’s also the secondary issue that it is valuable to be able to build these components out of tree, yet this is currently fragile and is likely to be broken even more if we’re insisting on the monorepo.

We are currently able to target our platform from LLVM (as a cross-compiler), but not build LLVM to run on it, so it is unhelpful to have stuff that we compile for x86 and stuff that we compile for our target in the same repo, because we aggregate the stuff that we build for the target (libunwind, libc++, and so on) when we build images.

Finally, there’s the philosophical / software engineering issue.  There should be no tight coupling between libunwind and anything else in the LLVM tree.  Libunwind implements a set of well-documented and stable APIs.  These are used by other components, but are equally useful in other contexts (i.e. any compiler for any language that uses the Itanium unwind model).  From the perspective of someone hacking on libunwind, LLVM is an unrelated project (though one that shares coding conventions - an analogy would be two projects under the Apache umbrella) and there is absolutely no reason to insist that libunwind developers should clone a massive unrelated project to work on the code that they want to work on.

All of this applies to libc++ and libc++abi as well.

David