mirror of
https://github.com/capstone-engine/llvm-capstone.git
synced 2024-10-07 19:03:57 +00:00
c6bd873403
With the new behaviour, the /MD or similar options aren't added to e.g. CMAKE_CXX_FLAGS_RELEASE, but are added separately by CMake. They can be changed by the cmake variable CMAKE_MSVC_RUNTIME_LIBRARY or with the target property MSVC_RUNTIME_LIBRARY. LLVM has had its own custom CMake flags, e.g. LLVM_USE_CRT_RELEASE, which affects which CRT is used for release mode builds. Deprecate these and direct users to use CMAKE_MSVC_RUNTIME_LIBRARY directly instead (and do a best effort attempt at setting CMAKE_MSVC_RUNTIME_LIBRARY based on the existing LLVM_USE_CRT_ flags). This only handles the simple cases, it doesn't handle multi-config generators with different LLVM_USE_CRT_* variables for different configs though, but that's probably fine - we should move over to the new upstream CMake mechanism anyway, and push users towards that. Change code in compiler-rt, that previously tried to override the CRT choice to /MT, to set CMAKE_MSVC_RUNTIME_LIBRARY instead of meddling in the old variables. This resolves the policy issue in https://github.com/llvm/llvm-project/issues/63286, and should handle the issues that were observed originally when the minimum CMake version was bumped, in https://github.com/llvm/llvm-project/issues/62719 and https://github.com/llvm/llvm-project/issues/62739. Differential Revision: https://reviews.llvm.org/D155233 |
||
|---|---|---|
| .. | ||
| 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.