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:
/libcxx
/libcxxabi
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.
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.
Agreed. Let’s talk about any code sharing ahead of time though if you wouldn’t mind
There’s a few candidates:
CMake functions that could be used by both
the atomic_support.h header copy-pasted into libc++
I think EricWF has a laundry list of technical debt we’ve accumulated because of this.
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”?
Agreed. Let’s talk about any code sharing ahead of time though if you wouldn’t mind
There’s a few candidates:
CMake functions that could be used by both
Anything build system related is great in my book.
the atomic_support.h header copy-pasted into libc++
I think EricWF has a laundry list of technical debt we’ve accumulated because of this.
nod
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”?
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
We can, however I'd like to note that I've done a lot of CMake refactoring in libc++ and libc++abi in a way that those would benefit from this, but none in libunwind.
I think libunwind won't benefit quite as much until it gets the love it needs, but I don't see a strong reason not to require libunwind/ too. After all, it's part of the C++ Runtime as well, so it makes sense at least from a conceptual perspective.
Agreed. Let’s talk about any code sharing ahead of time though if you wouldn’t mind
There’s a few candidates:
CMake functions that could be used by both
Anything build system related is great in my book.
the atomic_support.h header copy-pasted into libc++
I think EricWF has a laundry list of technical debt we’ve accumulated because of this.
nod
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”?
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
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.
I’m fully in support of requiring the monorepo setup.
I would like to go a step further, and unify libc++, libc++abi, and libunwind to share the same set of CMake configuration options.
For example, instead of LIBCXX_BUILD_32_BITS, LIBCXXABI_BUILD_32_BITS, LIBUNWIND_BUILD_32_BITS, they would all
share RUNTIMES_BUILD_32_BITS. Other examples:
Unifying the projects under a single CMake configuration would also allow us to use target names to express dependencies and
to pass interface flags around. So instead of libc++abi having to search for the libc++ headers and library to use, and then manually
setting up the flags, it could simply do add_dependencies(cxxabi cxx) target_link_libraries(cxxabi cxx) .
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++).
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
do the work twice.
It sounds to me like maybe the right thing to do here is to introduce a new sub-directory for shared build infrastructure, which could be used across any/all of the subprojects whether or not they have dependencies on other components. Maybe call it “common”?
Initially, I’d propose starting small, and restrict the scope of this to be for CMake infrastructure only. But, I can imagine that eventually we might wish to expand the scope to include other important infrastructure like lit (which isn’t really part of llvm-the-library, and is important for testing parts of llvm-the-project which don’t need to depend on llvm-the-library.)
I’m fully in support of requiring the monorepo setup.
I would like to go a step further, and unify libc++, libc++abi, and libunwind to share the same set of CMake configuration options.
Compiler-rt too.
Compiler-rt is a weird one. Because it builds multiple versions of libc++ as dependencies.
I’m not sure all of it so neatly fits under this umbrella, but I know compiler-rt could benefit from tighter integration.
Including Chris and Shoaib in case they’re not on libcxx-dev. I think this discussion might be more suited for llvm-dev now that we’re discussing other runtimes.
This is something we’ve discussed during the round table about build and CMake at the last devmtg. The idea was to introduce a new top-level directory, e.g. cmake, to hold all the shared build infrastructure. Today, there are a number of cmake/Modules across compiler-rt, libcxx, libcxxabi, libunwind that started as pure copies have since diverged which makes changes particularly painful.
Regarding compiler-rt, the tentative plan is to break it down into (at least) two subprojects: one that doesn’t have any dependencies which today would be builtins and crt, and another one that would contain runtimes that rely on libcxxabi/libcxx which would be all sanitizers and probably everything else. This would also allow build simplification and help with ordering issues we have today.
I love what I’m seeing, which is a lot of enthusiasm. I’m also unsure about compiler-rt, and actually libunwind too. But it doesn’t matter, cause we can take things slowly and try stuff out.
For starters, I’ll get rid of obvious technical debt between libc++ and libc++abi. We can see where that takes us next. Just be on the look for Phab reviews if that’s of interest to you.
Agreed. Let’s talk about any code sharing ahead of time though if you wouldn’t mind
There’s a few candidates:
CMake functions that could be used by both
Anything build system related is great in my book.
the atomic_support.h header copy-pasted into libc++
I think EricWF has a laundry list of technical debt we’ve accumulated because of this.
nod
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”?
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
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.
Excellent. I’ll add libunwind there myself if we wanted to go that direction. That said, I have no issues, just wanted to make sure.
