<div dir="ltr"><div>I'm fully in support of requiring the monorepo setup.</div><div>I would like to go a step further, and unify libc++, libc++abi, and libunwind to share the same set of CMake configuration options.<br></div><div><br></div><div>For example, instead of LIBCXX_BUILD_32_BITS, LIBCXXABI_BUILD_32_BITS, LIBUNWIND_BUILD_32_BITS, they would all</div><div>share RUNTIMES_BUILD_32_BITS. Other examples:</div><div><br></div><div><span style="color:rgb(36,41,46);font-family:SFMono-Regular,Consolas,"Liberation Mono",Menlo,monospace;font-size:12px;white-space:pre">LIB(UNWIND|CXX|CXXABI)_TARGET_TRIPLE</span><br></div><div><span style="color:rgb(36,41,46);font-family:SFMono-Regular,Consolas,"Liberation Mono",Menlo,monospace;font-size:12px;white-space:pre"> ||                   _GCC_TOOLCHAIN</span></div><div><span style="color:rgb(36,41,46);font-family:SFMono-Regular,Consolas,"Liberation Mono",Menlo,monospace;font-size:12px;white-space:pre"> ||                   _SYSROOT</span></div><div><span style="color:rgb(36,41,46);font-family:SFMono-Regular,Consolas,"Liberation Mono",Menlo,monospace;font-size:12px;white-space:pre">LIBCXX(ABI|)_ENABLE_NEW_DELETE_DEFINITIONS</span></div><div><span style="color:rgb(36,41,46);font-family:SFMono-Regular,Consolas,"Liberation Mono",Menlo,monospace;font-size:12px;white-space:pre">LIBCXX(ABI|)_HAS_EXTERNAL_THREAD_API</span> <br></div><div><br></div><div>and the list goes on.</div><div><br></div><div>Unifying the projects under a single CMake configuration would also allow us to use target names to express dependencies and</div><div>to pass interface flags around. So instead of libc++abi having to search for the libc++ headers and library to use, and then manually</div><div>setting up the flags, it could simply do `add_dependencies(cxxabi cxx) target_link_libraries(cxxabi cxx)` .<br></div><div><br></div><div>I'll hold short of suggesting that libc++abi should be moved under libc++ (while still allowing other ABI libraries to be used with libc++).</div><div>But that's my ideal scenario. The libc++abi and libc++ object files should already be built with the same set of flags/configuration, but we</div><div>do the work twice. </div><div><br></div><div>=========================</div><div><br></div><div>On another note, it would be nice if the LLVM libraries could be disabled using LLVM_ENABLE_PROJECTS.</div><div>That way `ninja build` and `ninja install` could be used effectively when just building the runtimes.</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Mar 11, 2020 at 2:52 PM Louis Dionne <<a href="mailto:ldionne@apple.com">ldionne@apple.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><br><div><br><blockquote type="cite"><div>On Mar 11, 2020, at 14:34, Eric Christopher <<a href="mailto:echristo@gmail.com" target="_blank">echristo@gmail.com</a>> wrote:</div><br><div><div dir="ltr"><div><a class="gmail_plusreply" id="gmail-m_-7515242057995754774plusReplyChip-0" href="mailto:jgorbe@google.com" target="_blank">+Jorge Gorbe Moya</a> <a class="gmail_plusreply" id="gmail-m_-7515242057995754774plusReplyChip-1" href="mailto:saugustine@google.com" target="_blank">+saugustine@google.com</a> <br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Mar 11, 2020 at 11:31 AM Louis Dionne <<a href="mailto:ldionne@apple.com" target="_blank">ldionne@apple.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>+EricWF<br><div><br><blockquote type="cite"><div>On Mar 11, 2020, at 14:07, Eric Christopher <<a href="mailto:echristo@gmail.com" target="_blank">echristo@gmail.com</a>> wrote:</div><br><div><div dir="auto">Agreed. Let's talk about any code sharing ahead of time though if you wouldn't mind :)</div></div></blockquote><div><br></div><div>There's a few candidates:</div><div>- CMake functions that could be used by both</div></div></div></blockquote><div><br></div><div>Anything build system related is great in my book.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div><div>- the atomic_support.h header copy-pasted into libc++</div><div><br></div><div>I think EricWF has a laundry list of technical debt we've accumulated because of this.</div><div><br></div></div></div></blockquote><div><br></div><div>*nod*</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div><div></div><div>Eric (echristo@), is opening a Phab review with those code sharing changes sufficient, or did you mean something additional by "talk about code sharing ahead of time"?</div><blockquote type="cite"><div><br></div></blockquote></div></div></blockquote><div>A phab review sounds good to me, I was mostly concerned with sharing in libc++abi in such a way that it wasn't separately buildable if necessary, etc. Probably not really a worry, but just wanted to think about it. If something happens and it breaks some use cases terribly we can also just bring it up :)</div></div></div></div></blockquote><div><br></div><div>If by "separately buildable" you mean building libc++abi.dylib (and its headers) as a standalone build product, then we will for sure retain that. I personally have use cases for that and I strongly suspect many others do, too.</div><div><br></div><div>Louis</div><br><blockquote type="cite"><div><div dir="ltr"><div class="gmail_quote"><div><br></div><div>-eric</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div><blockquote type="cite"><div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Mar 11, 2020, 10:50 AM James Y Knight via libcxx-dev <<a href="mailto:libcxx-dev@lists.llvm.org" target="_blank">libcxx-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">+1. Any simplifications and cleanups of the buildsystem SGTM.<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Mar 11, 2020 at 1:28 PM Louis Dionne via libcxx-dev <<a href="mailto:libcxx-dev@lists.llvm.org" rel="noreferrer" target="_blank">libcxx-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>Hey folks,<div><br></div><div>Now that the monorepo is the standard, would everybody be fine with requiring both libc++ and libc++abi sources to be accessible in a monorepo-like layout when building either of them? In other words, in order to build either libc++ or libc++abi, we would require the following layout:</div><div><br></div><div><font face="Monaco"><span style="font-style:normal">   <root>/libcxx</span></font></div><div><font face="Monaco"><span style="font-style:normal">   <root>/libcxxabi</span></font></div><div><br></div><div>I suggest not requiring the rest of the monorepo, simply because it wouldn't be useful, and I know of at least one use case that would break.</div><div><br></div><div>The benefit of adopting this assumption is that all the search for libcxx and libcxxabi sources can be removed, simplifying the build quite a bit. Eventually, we can even start sharing stuff between the two sub-projects. If we go forward with this, I'll be happy to make the clean ups I mention.</div><div><br></div><div>Cheers,</div><div>Louis</div></div></blockquote></div></blockquote></div></div></blockquote></div><br></div></blockquote></div></div>
</div></blockquote></div><br></div></blockquote></div>