<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jun 29, 2016 at 9:28 AM, James Y Knight via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="">On Mon, Jun 27, 2016 at 12:13 PM, Renato Golin via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span>On 27 June 2016 at 17:03, Rafael Espíndola <<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@gmail.com</a>> wrote:<br>
> I think that trying to create a ordering/rev number between independent git<br>
> repositories is fundamentally unreliable.<br>
><br>
> If we want to keep llvm and clang in lock step we should probably probably<br>
> just have them in the same repository like<br>
> <a href="https://github.com/llvm-project/llvm-project" rel="noreferrer" target="_blank">https://github.com/llvm-project/llvm-project</a>.<br>
<br>
</span>That is similar to the proposal we have, except that llvm-projects<br>
will have sub-modules.<br>
<br>
Having all of them in the same physical repository is a big problems<br>
for those that only use a small subset of the components, which is the<br>
vast majority of users, most of the time (all buildbots, Jenkins,<br>
local development, downstream users, even releases don't clone all<br>
repos).</blockquote><div><br></div></span><div>(This is kinda a sidenote, because it doesn't actually change the problem-space at all, but.... :)</div><div><br></div><div>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.</div></div></div></div></blockquote><div><br></div><div>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).</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>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.</div></div></div></div></blockquote><div><br></div><div>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".</div><div><br></div><div>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".</div><div><br></div><div>Just my 2c</div><div><br></div><div>-- Sean Silva</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>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....</div></div></div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>E.g.:<br></div><div>llvm: Core language-independent functionality: LLVM, assembler, and linker tools. (merge in lld, and maybe compiler-rt, to the llvm repository).<br></div><div>clang: C/C++ frontend and related libraries (merge in clang-tools-extra, libcxx, and libcxxabi into the clang repository).</div><div><br></div><div><br></div></div></div></div>
<br>_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
<br></blockquote></div><br></div></div>