Michael Kruse afb80bddf1
[Runtimes] Introduce variables containing resource dir paths (#177953)
Introduce common infrastructure for runtimes that determines compiler
resource path locations. These variables introduced are:

 * RUNTIMES_OUTPUT_RESOURCE_DIR
 * RUNTIMES_INSTALL_RESOURCE_PATH
 
That contain the location for the compiler resource path (typically
`lib/clang/<version>`) in the build tree and the install tree (the
latter relative to CMAKE_INSTALL_PREFIX).

Additionally, define

 * RUNTIMES_OUTPUT_RESOURCE_LIB_DIR
 * RUNTIMES_INSTALL_RESOURCE_LIB_PATH

as for the location of clang/flang version-locked libraries (typically
`lib${LLVM_LIBDIR_SUFFIX}/<targer-triple>`, but also depends on `APPLE`
and `LLVM_ENABLE_PER_TARGET_RUNTIME_DIR`). This code is moved from
flang-rt and initially becomes its only user.

Refactored out of #171610 as requested
[here](https://github.com/llvm/llvm-project/pull/171610#discussion_r2687382481).

Extracted `get_runtimes_target_libdir_common` from compiler-rt as
requested
[here](https://github.com/llvm/llvm-project/pull/171610#discussion_r2689565634).
 
Added TODO comments to all runtimes as requested
[here](https://github.com/llvm/llvm-project/pull/171610#issuecomment-3789598635).
2026-04-02 10:32:14 +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 ${CMAKE_CURRENT_SOURCE_DIR}/../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 ${CMAKE_CURRENT_SOURCE_DIR}/../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.