llvm/cmake
John Ericson 7017e6c9cf [cmake] Partially deduplicate {llvm,compiler_rt}_check_linker_flag for runtime libs and llvm
We previously had a few varied definitions of this floating around.

I had tried to make the one installed with LLVM handle all the cases, and then made the others use it, but this ran into issues with `HandleOutOfTreeLLVM` not working for compiler-rt, and also `CMAKE_EXE_LINKER_FLAGS` not working right without `CMP0056` set to the new behavior.

 My compromise solution is this:

 - No not completely deduplicate: the runtime libs will instead use a version that still exists as part of the internal and not installed common shared CMake utilities. This avoids `HandleOutOfTreeLLVM` or a workaround for compiler-rt.

- Continue to use `CMAKE_REQUIRED_FLAGS`, which effects compilation and linking. Maybe this is unnecessary, but it's safer to leave that as a future change. Also means we can avoid `CMP0056` for now, to try out later, which is good incrementality too.

- Call it `llvm_check_compiler_linker_flag` since it, in fact is about both per its implementation (before and after this patch), so there is no name collision.

In the future, we might still enable CMP0056 and make compiler-rt work with HandleOutOfTreeLLVM, which case we delete `llvm_check_compiler_flag` and go back to the old way (as these are, in fact, linking related flags), but that I leave for someone else as future work.

The original issue was reported to me in https://reviews.llvm.org/D116521#3248117 as
D116521 made clang and LLVM use the common cmake utils.

Reviewed By: sebastian-ne, phosek, #libunwind, #libc, #libc_abi, ldionne

Differential Revision: https://reviews.llvm.org/D117537
2022-01-29 06:07:24 +00:00
..
Modules [cmake] Partially deduplicate {llvm,compiler_rt}_check_linker_flag for runtime libs and llvm 2022-01-29 06:07:24 +00:00
README.rst [doc][cmake] Convert read-me for the common CMake utils to reST 2022-01-10 21:36:11 +00:00

=======================
LLVM Common CMake Utils
=======================

What goes here
--------------

These are CMake modules to be shared between LLVM projects strictly at build
time. In other words, they must not be included from an installed CMake module,
such as the ``Add*.cmake`` ones. Modules that are reachable from installed
modules should instead go in ``${project}/cmake/modules`` of the most upstream
project that uses them.

The advantage of not putting these modules in an existing location like
``llvm/cmake/modules`` is two-fold:

- Since they are not installed, we don't have to worry about any out-of-tree
  downstream usage, and thus there is no need for stability.

- Since they are available as part of the source at build-time, we don't have
  to do the usual stand-alone vs combined-build dances, avoiding much
  complexity.

How to use
----------

For tools, please do:

.. code-block:: cmake

  if(NOT DEFINED LLVM_COMMON_CMAKE_UTILS)
    set(LLVM_COMMON_CMAKE_UTILS ${LLVM_COMMON_CMAKE_UTILS}/../cmake)
  endif()

  # Add path for custom modules.
  list(INSERT CMAKE_MODULE_PATH 0
    # project-specific module dirs first
    "${LLVM_COMMON_CMAKE_UTILS}/Modules"
    )

Notes:

- The ``if(NOT DEFINED ...)`` guard is there because in combined builds, LLVM
  will set this variable.  This is useful for legacy builds where projects are
  found in ``llvm/tools`` instead.

- ``INSERT ... 0`` ensures these new entries are prepended to the front of the
  module path, so nothing might shadow them by mistake.

For runtime libs, we skip the ``if(NOT DEFINED`` part:

.. code-block:: cmake

  set(LLVM_COMMON_CMAKE_UTILS ${LLVM_COMMON_CMAKE_UTILS}/../cmake)

  ... # same as before

If ``llvm/tools`` legacy-style combined builds are deprecated, we should then
skip it everywhere, bringing the tools and runtimes boilerplate back in line.