Petr Hosek via llvm-dev
2021-Oct-07 22:46 UTC
[llvm-dev] 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>
Brian Cain via llvm-dev
2021-Oct-08 00:34 UTC
[llvm-dev] [libcxx-dev] Introducing shared top-level CMake modules
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>
Michael Kruse via llvm-dev
2021-Oct-09 02:37 UTC
[llvm-dev] Introducing shared top-level CMake modules
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