[libcxx-dev] Requiring monorepo layout when building libc++ and libc++abi
Eric Fiselier via libcxx-dev
libcxx-dev at lists.llvm.org
Wed Mar 11 14:20:55 PDT 2020
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:
and the list goes on.
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.
On another note, it would be nice if the LLVM libraries could be disabled
That way `ninja build` and `ninja install` could be used effectively when
just building the runtimes.
On Wed, Mar 11, 2020 at 2:52 PM Louis Dionne <ldionne at apple.com> wrote:
> On Mar 11, 2020, at 14:34, Eric Christopher <echristo at gmail.com> wrote:
> +Jorge Gorbe Moya <jgorbe at google.com> +saugustine at google.com
> <saugustine at google.com>
> On Wed, Mar 11, 2020 at 11:31 AM Louis Dionne <ldionne at apple.com> wrote:
>> On Mar 11, 2020, at 14:07, Eric Christopher <echristo at gmail.com> wrote:
>> 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.
>> 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,
>> On Wed, Mar 11, 2020, 10:50 AM James Y Knight via libcxx-dev <
>> libcxx-dev at lists.llvm.org> wrote:
>>> +1. Any simplifications and cleanups of the buildsystem SGTM.
>>> On Wed, Mar 11, 2020 at 1:28 PM Louis Dionne via libcxx-dev <
>>> libcxx-dev at lists.llvm.org> wrote:
>>>> Hey folks,
>>>> 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:
>>>> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the libcxx-dev