ac0d1d5c7b
Firstly, we we make an additional GNUInstallDirs-style variable. With NixOS, for example, this is crucial as we want those to go in `${dev}/lib/cmake` not `${out}/lib/cmake` as that would a cmake subdir of the "regular" libdir, which is installed even when no one needs to do any development. Secondly, we make *Config.cmake robust to absolute package install paths. We for NixOS will in fact be passing them absolute paths to make the `${dev}` vs `${out}` distinction mentioned above, and the GNUInstallDirs-style variables are suposed to support absolute paths in general so it's good practice besides the NixOS use-case. Thirdly, we make `${project}_INSTALL_PACKAGE_DIR` CACHE PATHs like other install dirs are. Reviewed By: sebastian-ne Differential Revision: https://reviews.llvm.org/D117973 |
||
---|---|---|
.. | ||
Modules | ||
README.rst |
======================= 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.