[llvm-dev] Unifying CMake variable names used in checks across subprojects

[Petr Hosek via llvm-dev]

We've been using the runtimes build for a while now and we're very happy
with it. However, with an increasing number of targets, it can be fairly
slow and I have noticed that we now spend more time in CMake than in Ninja.
There are various ways we could improve things like eliminating unnecessary
checks.

When running checks like check_c_compiler_flag, check_cxx_compiler_flag
or check_library_exists, CMake caches the resulting variable and doesn't
run the check again. The problem is that in LLVM, each subproject uses
different variable names for results of these checks. For example, most
subprojects check if pthread is available and store the result in:

COMPILER_RT_HAS_LIBPTHREAD (compiler-rt)
LIBCXX_HAS_PTHREAD_LIB (libc++)
LIBCXXABI_HAS_PTHREAD_LIB (libc++abi)
LIBUNWIND_HAS_PTHREAD_LIB (libunwind)
HAVE_LIBPTHREAD (llvm)

This means that even though this check would ideally be performed just once
(per target) and reused everywhere, it's performed 5 times. The same is
true for most flags and library checks.

I think that this is really unnecessary and could be easily improved by
unifying CMake variable names used in checks across subprojects to benefit
from caching.

I've looked at naming conventions used across all subprojects and I'm
proposing the following:

C_SUPPORTS_${mangled_name}_FLAG for check_c_compiler_flag
CXX_SUPPORTS_${mangled_name}_FLAG for check_cxx_compiler_flag
HAVE_${mangled_name} for check_library_exists

Note: It'd be more consistent for check_library_exists to
use HAS_${mangled_name}_LIB but that's going to cause more churn in LLVM so
that's something to consider.

This change should be mostly invisible to LLVM developers (except for the
handful of build maintainers), but it should considerably speed up the
runtimes build and hopefully pave the way to eventually hoist most of the
common CMake logic into a shared location.

I'm happy to implement this change, but I want to get your opinion on the
proposal as well as the proposed naming.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200922/c1df543f/attachment.html>