llvm dev - Oct 2021 - Introducing shared top-level CMake modules

I'm about to land D88458 <https://reviews.llvm.org/D88458> which is
notable
because it extracts shared CMake logic that has been duplicated across
libc++, libc++abi, libunwind and compiler-rt and moves it to a shared
top-level CMake module.

We hope that this will reduce duplication and promote reuse in LLVM build,
but it also means that it'll not longer be possible to build projects
libc++, libc++abi, libunwind and compiler-rt using CMake without having the
full monorepo checkout (as opposed to just checking out slices) unless you
also check out the top-level CMake module directory.

We don't think this should introduce significant issues since requiring the
full monorepo checkout is something we've been already implicitly assuming
in various parts of our build, but I still want to call out this change in
case you see related issues, especially in downstream builds that aren't
covered by upstream bots.

We plan on following up with other changes in this direction (such as
D110005 <https://reviews.llvm.org/D110005>) which should in the long term
result in a simpler and faster CMake build.

Please let me know if you have any questions.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20211007/e912372f/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3996 bytes
Desc: S/MIME Cryptographic Signature
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20211007/e912372f/attachment.bin>

Petr,

Thanks for the heads up.  Will this impact builds that use
compiler-rt/libcxx/libcxxabi/libunwind as the entry directory (but present in a
monorepo checkout)?

Like so:

cmake -GNinja  … $XYZ/src/llvm-project/compiler-rt


From: libcxx-dev <libcxx-dev-bounces at lists.llvm.org> On Behalf Of Petr
Hosek via libcxx-dev
Sent: Thursday, October 7, 2021 5:46 PM
To: llvm-dev <llvm-dev at lists.llvm.org>; Libc++ Dev <libcxx-dev at
lists.llvm.org>
Subject: [libcxx-dev] Introducing shared top-level CMake modules


WARNING: This email originated from outside of Qualcomm. Please be wary of any
links or attachments, and do not enable macros.
I'm about to land D88458<https://reviews.llvm.org/D88458> which is
notable because it extracts shared CMake logic that has been duplicated across
libc++, libc++abi, libunwind and compiler-rt and moves it to a shared top-level
CMake module.

We hope that this will reduce duplication and promote reuse in LLVM build, but
it also means that it'll not longer be possible to build projects libc++,
libc++abi, libunwind and compiler-rt using CMake without having the full
monorepo checkout (as opposed to just checking out slices) unless you also check
out the top-level CMake module directory.

We don't think this should introduce significant issues since requiring the
full monorepo checkout is something we've been already implicitly assuming
in various parts of our build, but I still want to call out this change in case
you see related issues, especially in downstream builds that aren't covered
by upstream bots.

We plan on following up with other changes in this direction (such as
D110005<https://reviews.llvm.org/D110005>) which should in the long term
result in a simpler and faster CMake build.

Please let me know if you have any questions.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20211008/938f9c41/attachment.html>

Did you consider that the zorg buildbot has a filter for the
subdirectory? That is,a change to the top-level cmake directory will
not trigger a build because `cmake` does not match any subproject
(Same issue with the `runtimes` top-level directory).

Michael



Am Do., 7. Okt. 2021 um 17:46 Uhr schrieb Petr Hosek via llvm-dev
<llvm-dev at lists.llvm.org>:
>
> I'm about to land D88458 which is notable because it extracts shared
CMake logic that has been duplicated across libc++, libc++abi, libunwind and
compiler-rt and moves it to a shared top-level CMake module.
>
> We hope that this will reduce duplication and promote reuse in LLVM build,
but it also means that it'll not longer be possible to build projects
libc++, libc++abi, libunwind and compiler-rt using CMake without having the full
monorepo checkout (as opposed to just checking out slices) unless you also check
out the top-level CMake module directory.
>
> We don't think this should introduce significant issues since requiring
the full monorepo checkout is something we've been already implicitly
assuming in various parts of our build, but I still want to call out this change
in case you see related issues, especially in downstream builds that aren't
covered by upstream bots.
>
> We plan on following up with other changes in this direction (such as
D110005) which should in the long term result in a simpler and faster CMake
build.
>
> Please let me know if you have any questions.
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev