Introducing shared top-level CMake modules

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.

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

This change shouldn’t affect that use case.

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