<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">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><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><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><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><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>