mirror of
https://github.com/capstone-engine/llvm-capstone.git
synced 2025-01-19 14:44:39 +00:00
cbaa3597aa
This reverts commit d763c6e5e2d0a6b34097aa7dabca31e9aff9b0b6. Adds the patch by @hans from https://github.com/llvm/llvm-project/issues/62719 This patch fixes the Windows build. d763c6e5e2d0a6b34097aa7dabca31e9aff9b0b6 reverted the reviews D144509 [CMake] Bumps minimum version to 3.20.0. This partly undoes D137724. This change has been discussed on discourse https://discourse.llvm.org/t/rfc-upgrading-llvms-minimum-required-cmake-version/66193 Note this does not remove work-arounds for older CMake versions, that will be done in followup patches. D150532 [OpenMP] Compile assembly files as ASM, not C Since CMake 3.20, CMake explicitly passes "-x c" (or equivalent) when compiling a file which has been set as having the language C. This behaviour change only takes place if "cmake_minimum_required" is set to 3.20 or newer, or if the policy CMP0119 is set to new. Attempting to compile assembly files with "-x c" fails, however this is workarounded in many cases, as OpenMP overrides this with "-x assembler-with-cpp", however this is only added for non-Windows targets. Thus, after increasing cmake_minimum_required to 3.20, this breaks compiling the GNU assembly for Windows targets; the GNU assembly is used for ARM and AArch64 Windows targets when building with Clang. This patch unbreaks that. D150688 [cmake] Set CMP0091 to fix Windows builds after the cmake_minimum_required bump The build uses other mechanism to select the runtime. Fixes #62719 Reviewed By: #libc, Mordante Differential Revision: https://reviews.llvm.org/D151344
=======================
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.