<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2017-05-09 5:47 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 8 May 2017, at 20:51, Mehdi AMINI <<a href="mailto:joker.eph@gmail.com">joker.eph@gmail.com</a>> wrote:<br>
><br>
><br>
> 2017-05-07 1:01 GMT-07:00 David Chisnall via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>>:<br>
> Is this intended to be the monorepo that eventually becomes the official repo, because if so I strongly object to putting libunwind, libc++ and libc++abi in it.  I have recently been working on bring-up for libc++ and libunwind on a new platform and the integration of libunwind with the LLVM build system is already annoying (you can’t build it unless you have a working C++ standard library implementation for your target, even thought it’s a dependency for libc++), having to have a complete LLVM checkout would be even more overhead.<br>
><br>
> Please clarify the overhead.<br>
<br>
</span>My clone of libunwind is around 4MB.  A clone of LLVM is 2-3 orders of magnitude bigger.  The clone on my local system doesn’t matter too much (though it would be an annoying waste), because I have spare disk space, but each project, once it’s working, also gets cloned to our CI system, which is always short on disk space because it archives build artefacts.  Network bandwidth is also an issue.<br></blockquote><div><br></div><div>I'd expect any CI system to be able to cache this.</div><div>Also if you're issue is archiving a lot of build artifacts, the constant cost of the checkout isn't gonna matter that much.</div><div>Finally, the read-only individual repo can still be used by CI, which address this entirely.</div><div><br></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">
There’s also the secondary issue that it is valuable to be able to build these components out of tree, yet this is currently fragile and is likely to be broken even more if we’re insisting on the monorepo.<br></blockquote><div><br></div><div>I don't see any rational for this.</div><div>Whatever has a CI is gonna continue to work. This is already the case today: if you care about a configuration, provide CI for it and it'll continue to work.</div><div><br></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>
We are currently able to target our platform from LLVM (as a cross-compiler), but not build LLVM to run on it, so it is unhelpful to have stuff that we compile for x86 and stuff that we compile for our target in the same repo, because we aggregate the stuff that we build for the target (libunwind, libc++, and so on) when we build images.<br>
<br>
Finally, there’s the philosophical / software engineering issue.  There should be no tight coupling between libunwind and anything else in the LLVM tree.  Libunwind implements a set of well-documented and stable APIs.  These are used by other components, but are equally useful in other contexts (i.e. any compiler for any language that uses the Itanium unwind model).  From the perspective of someone hacking on libunwind, LLVM is an unrelated project (though one that shares coding conventions - an analogy would be two projects under the Apache umbrella) and there is absolutely no reason to insist that libunwind developers should clone a massive unrelated project to work on the code that they want to work on.<br></blockquote><div><br></div><div>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.</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">
<br>
All of this applies to libc++ and libc++abi as well.<br></blockquote><div><br></div><div>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></div><div>We duplicate the demangler from libc++abi in llvm for instance, and this is quite an important software engineer issue to me.<br></div><div><br></div><div><br></div><div>-- </div><div>Mehdi</div><div><br></div></div><br></div></div>