<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Thu, Oct 18, 2018 at 12:03 PM Martin Storsjö via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Thu, 18 Oct 2018, Renato Golin via llvm-dev wrote:<br>
<br>
> On Thu, 18 Oct 2018 at 14:19, David Chisnall via llvm-dev<br>
> <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
>> I would still prefer that projects that are not tightly coupled to LLVM (lib*, pstl, compiler-rt) be in separate repositories.  These do not link against LLVM libraries, are not version locked to any given LLVM / clang / whatever release, and most of them need to support multiple LLVM releases, so there is little benefit to having them in the monorepo and there is a disadvantage for people wishing to use and contribute to them independent of the rest of LLVM.<br>
><br>
> This sounds like:<br>
><br>
> Mono-repo:<br>
><br>
>>   * cfe -> clang<br>
>>   * clang-tools-extra<br>
>>   * llvm<br>
>>   * llgo ??<br>
><br>
> Separate - Core Libs (4 repos or all-in-one?):<br>
><br>
>>   * compiler-rt<br>
>>   * libcxx<br>
>>   * libcxxabi<br>
>>   * libunwind<br>
<br>
+1 from me for this layout as well. (Ideally maybe with all these 4 libs <br>
separately.)</blockquote><div><br></div><div>FWIW, this was discussed repeatedly and extensively.</div><div><br></div><div>At the end of the day, there was (slightly) more support for just having one, and so that's what folks have made progress implementing.</div><div><br></div><div>Personally, I'm much more in favor of the current prototype layout. But I'm even more in favor with getting this stuff to github sooner rather than later.<br></div><div><br></div><div>There are a bunch of ideas about how to effectively allow people to *consume* these libraries in reasonable ways despite them being developed in a monorepo. I think we should focus on working on these, seeing how well they work, and getting them to provide an adequate model. It may not be perfect, but my impression from all of the discussions is that this will be the least bad overall.</div></div></div>