[libcxx-dev] Requiring monorepo layout when building libc++ and libc++abi

[Eric Fiselier via libcxx-dev]

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:

LIB(UNWIND|CXX|CXXABI)_TARGET_TRIPLE
|| _GCC_TOOLCHAIN
|| _SYSROOT
LIBCXX(ABI|)_ENABLE_NEW_DELETE_DEFINITIONS
LIBCXX(ABI|)_HAS_EXTERNAL_THREAD_API

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
using LLVM_ENABLE_PROJECTS.
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:
>
>> +EricWF
>>
>> 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.
>>
>>
> *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.
>
> Louis
>
>
> -eric
>
>
>
>> 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:
>>>>
>>>>    <root>/libcxx
>>>>    <root>/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.
>>>>
>>>> Cheers,
>>>> Louis
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/libcxx-dev/attachments/20200311/a83a735f/attachment.html>