[libcxx-commits] [PATCH] D88458: [CMake] Cache compiler-rt library results

Louis Dionne via Phabricator via libcxx-commits libcxx-commits at lists.llvm.org
Wed Sep 30 11:09:11 PDT 2020


ldionne added a comment.

In D88458#2304175 <https://reviews.llvm.org/D88458#2304175>, @phosek wrote:

> In D88458#2304125 <https://reviews.llvm.org/D88458#2304125>, @ldionne wrote:
>
>> In D88458#2302188 <https://reviews.llvm.org/D88458#2302188>, @phosek wrote:
>>
>>> In D88458#2302059 <https://reviews.llvm.org/D88458#2302059>, @compnerd wrote:
>>>
>>>> If we require LLVM for any of the projects, perhaps we should hoist the `HandleCompilerRT.cmake` into LLVM and avoid having to maintain the copy everywhere.
>>>
>>> That's the eventual plan but we haven't yet figured out how the sharing is going to work.
>>
>> What do you mean? Just `include(...)` the file from the various projects?
>
> When migrating to monorepo, we discussed a plan to provide slices for individual projects. While these haven't been provided officially,  we already have these for our own purposes (e.g. https://llvm.googlesource.com/llvm-project/libcxx/) and they are used by projects like Chromium. A potential solution would be extend the machinery so that the content of `<llvm-project>/cmake/Modules` is copied into each slice?

I wasn't aware of that, and libc++ / libc++abi don't support that. See http://lists.llvm.org/pipermail/libcxx-dev/2020-March/000714.html for example.

In libc++ and libc++abi, we make the assumption that we're checked out at the root of the monorepo. Please sell me the need to support something else, because the only benefit I can think of is "it's faster to clone just libc++", which is not a strong argument to justify such code duplication.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D88458/new/

https://reviews.llvm.org/D88458



More information about the libcxx-commits mailing list