<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2017-05-09 8:17 GMT-07:00 David Chisnall <span dir="ltr"><<a href="mailto:David.Chisnall@cl.cam.ac.uk" target="_blank">David.Chisnall@cl.cam.ac.uk</a>></span>:<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 class="gmail-">On 9 May 2017, at 15:58, Mehdi AMINI <<a href="mailto:joker.eph@gmail.com">joker.eph@gmail.com</a>> wrote:<br>
<br>
> I'd expect any CI system to be able to cache this.<br>
> Also if you're issue is archiving a lot of build artifacts, the constant cost of the checkout isn't gonna matter that much.<br>
> Finally, the read-only individual repo can still be used by CI, which address this entirely.<br>
<br>
</span>If we want to pull in new libunwind fixes from upstream, we’ll also pull in irrelevant LLVM, clang, lldb, lld, and so on changes.  This translates to extra bandwidth and storage requirements for *every* copy of the libunwind repo that we need.<br></blockquote><div><br></div><div>I'm not sure if you really read the last sentence of what I wrote, or if you followed the previous discussions on the plan here?</div><div>At this point I believe that this concern is non-existent per the read-only individual repo.</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">
<br>
If we follow the monorepo approach downstream and merge these independent repos, then we add extra merges for everyone downstream because people committing improvements to our LLVM and clang trees will require rebase pulls for anyone working on libc++ or libunwind, even though the changes were to a component that they’re not needing to build, let alone modify.<br></blockquote><div><br></div><div>Every downstream has its own choice, I'm not sure what's the point here? If it is not relevant to you, then don't do it...</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">
<span class="gmail-"><br>
> There is another philosophical perspective: encouraging communities to get closer together. You talking about "libunwind developers", and there are "lldb developers" as well, I rather get closer to: "we're working on the same project", with shared practices and goals. And ultimately, to come back to your software engineering practices, encouraging code motion and code reuse between sub-projects.<br>
<br>
</span>I disagree,  [...].<br></blockquote><div><br></div><div>We can leave it there :)</div><div>There have been extensive discussions, a BoF, and documentations, please refer you to these first (granted we haven't really talked about libunwind, but I'm not sure many people will be strongly opposed to libunwind having its separate life).</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">
<span class="gmail-"><br>
>> All of this applies to libc++ and libc++abi as well.<br>
><br>
> Ultimately I don't know about libunwind, and if it has to live separately it is not a big deal. The others (libc++ and libc++abi for instance) are more tied to the rest of the project though.<br>
> We duplicate the demangler from libc++abi in llvm for instance, and this is quite an important software engineer issue to me.<br>
<br>
</span>The requirements for a libc++abi demangler and a generic LLVM one are very different.  <br></blockquote><div><br></div><div><br></div><div>They are so different that we ask anyone who want to change something to the LLVM demangler to make the change in compiler-rt first and then pull the patch...</div><div>Maintaining two demanglers (or more) is silly IMO (no-one is even maintaining the existing one...).</div><div><br></div><div>-- </div><div>Mehdi</div><div><br></div><div> <br></div></div></div></div>