[lldb-dev] [llvm-dev] Git Move: GitHub+modules proposal

[Sean Silva via lldb-dev]

On Wed, Jun 29, 2016 at 9:28 AM, James Y Knight via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> On Mon, Jun 27, 2016 at 12:13 PM, Renato Golin via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> On 27 June 2016 at 17:03, Rafael Espíndola <rafael.espindola at gmail.com>
>> wrote:
>> > I think that trying to create a ordering/rev number between independent
>> git
>> > repositories is fundamentally unreliable.
>> >
>> > If we want to keep llvm and clang in lock step we should probably
>> probably
>> > just have them in the same repository like
>> > https://github.com/llvm-project/llvm-project.
>>
>> That is similar to the proposal we have, except that llvm-projects
>> will have sub-modules.
>>
>> Having all of them in the same physical repository is a big problems
>> for those that only use a small subset of the components, which is the
>> vast majority of users, most of the time (all buildbots, Jenkins,
>> local development, downstream users, even releases don't clone all
>> repos).
>
>
> (This is kinda a sidenote, because it doesn't actually change the
> problem-space at all, but.... :)
>
> I really disagree that it'd cause big problems to merge them all.
> Especially when using git, which makes it a lot easier to keep a local
> shared copy of the repository, so you don't need to re-download the whole
> world every time you want a clean checkout. The entire set of llvm code,
> all put together, is really just not that big in the end. But I do find it
> annoying to have the many different repositories to track, and I don't
> really see the value of having as many as we do.
>

This is anecdotal, but using llvm-project on a ~daily basis, I can say that
the place where the larger repo is noticeable is the increased size of the
checkout; this affects the time of `git status` and many other frequently
used commands. It isn't terrible though (even on windows; at least with an
SSD; I haven't tried HDD).


>
> However, even without big problems, it does make some sense to keep the
> C/C++ language separate from the (mostly-)language-independent llvm
> backend. There are a multitude of other frontends which use LLVM too: go,
> swift, rust, etc. Would we really want to pull in all of those into a
> single repo, as well, if they happened to get contributed to the llvm
> project organization? Probably not.
>

Clang is special in that we have the expectation that developers need to
update clang if their patch to LLVM breaks it. (I assume this is largely
due to its role in self-hosting). It is unlikely that any other frontend
will ever get that special treatment since it does entail a high
maintenance burden. So I don't see a strong reason to split out clang just
because it is a "frontend".

Roughly speaking, I would prefer a repo division (if any) to be along the
lines of "core toolchain" (clang, llvm, lld, compiler-rt) and "extra stuff
not strictly required".

Just my 2c

-- Sean Silva


> So, while this wouldn't affect the need for a "llvm-project" repository,
> it might be nice to consider merging some of the other ones together....
>

> E.g.:
> llvm: Core language-independent functionality: LLVM, assembler, and linker
> tools. (merge in lld, and maybe compiler-rt, to the llvm repository).
> clang: C/C++ frontend and related libraries (merge in clang-tools-extra,
> libcxx, and libcxxabi into the clang repository).
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20160629/4acd8a7e/attachment.html>