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

[James Y Knight via libcxx-dev]

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.)


On Wed, Mar 11, 2020 at 5:21 PM Eric Fiselier <ericwf at google.com> wrote:

> 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/c2ca76dc/attachment-0001.html>