llvm dev - Jun 2016 - Git Move: GitHub+modules proposal

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/llvm-dev/attachments/20160629/4acd8a7e/attachment.html>

On 29 June 2016 at 19:51, Sean Silva <chisophugis at gmail.com>
wrote:
> 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".
The problem comes when different people consider "core" different
projects. :)

We're always reviewing the projects and we do split them when people
agree it's needed.

Examples are the libunwind coming out of Compiler-RT, and the recent
discussion to do the same with the sanitizers and others. This is not
just about preference, but it's about cross dependency, and the only
sane way we can cross-build to multiple targets.

cheers,
--renato

On Wed, Jun 29, 2016 at 12:04 PM, Renato Golin <renato.golin at
linaro.org>
wrote:
> On 29 June 2016 at 19:51, Sean Silva <chisophugis at gmail.com>
wrote:
> > 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".
>
> The problem comes when different people consider "core" different
> projects. :)
>
Sure. But selfhost (incl. stuff like selfhost w/ sanitizers) is a fairly
important special case we may be able to agree on. (and I say this as
somebody that largely builds cross-compilers (targeting PS4))

-- Sean Silva

>
> We're always reviewing the projects and we do split them when people
> agree it's needed.
>
> Examples are the libunwind coming out of Compiler-RT, and the recent
> discussion to do the same with the sanitizers and others. This is not
> just about preference, but it's about cross dependency, and the only
> sane way we can cross-build to multiple targets.
>
> cheers,
> --renato
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160629/6ab7ce0d/attachment.html>