mirrors/llvm-project
0
0
Fork 0
mirror of https://github.com/llvm/llvm-project.git synced 2025-04-19 08:56:42 +00:00
Code Issues Projects Releases Wiki Activity
llvm-project/lld/CMakeLists.txt

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

241 lines
7.7 KiB
CMake
Raw Normal View History

Reland "[CMake] Bumps minimum version to 3.20.0. 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
2023-05-24 18:12:32 +02:00
cmake_minimum_required(VERSION 3.20.0)
[lld] Revise IDE folder structure (#89747) Update the folder titles for targets in the monorepository that have not seen taken care of for some time. These are the folders that targets are organized in Visual Studio and XCode (`set_property(TARGET <target> PROPERTY FOLDER "<title>")`) when using the respective CMake's IDE generator. * Ensure that every target is in a folder * Use a folder hierarchy with each LLVM subproject as a top-level folder * Use consistent folder names between subprojects * When using target-creating functions from AddLLVM.cmake, automatically deduce the folder. This reduces the number of `set_property`/`set_target_property`, but are still necessary when `add_custom_target`, `add_executable`, `add_library`, etc. are used. A LLVM_SUBPROJECT_TITLE definition is used for that in each subproject's root CMakeLists.txt.
2024-06-04 01:31:36 +02:00
set(LLVM_SUBPROJECT_TITLE "LLD")
[lld] Deprecate using llvm-config to detect llvm installation This is continuing in the path of D51714, which did this for Clang. I have rearranged the source code Clang so one can diff the top-level CMakeLists.txt of Clang and LLD, ensuring we use the same strategy for both. Besides diffing the two files, `git diff --color-moved` on LLD also helps review. Reviewed By: beanz Differential Revision: https://reviews.llvm.org/D116492
2022-01-02 06:29:26 +00:00
Harmonize cmake_policy() across standalone builds of all projects Move `cmake_policy()` settings from `llvm/CMakeLists.txt` into a shared `cmake/modules/CMakePolicy.cmake`. Include it from all relevant projects that support standalone builds, in order to ensure that the policies are consistently set whether they are built in-tree or stand-alone. Differential Revision: https://reviews.llvm.org/D136572
2022-10-24 06:31:37 +02:00
if(NOT DEFINED LLVM_COMMON_CMAKE_UTILS)
set(LLVM_COMMON_CMAKE_UTILS ${CMAKE_CURRENT_SOURCE_DIR}/../cmake)
endif()
include(${LLVM_COMMON_CMAKE_UTILS}/Modules/CMakePolicy.cmake
NO_POLICY_SCOPE)
[lld] Deprecate using llvm-config to detect llvm installation This is continuing in the path of D51714, which did this for Clang. I have rearranged the source code Clang so one can diff the top-level CMakeLists.txt of Clang and LLD, ensuring we use the same strategy for both. Besides diffing the two files, `git diff --color-moved` on LLD also helps review. Reviewed By: beanz Differential Revision: https://reviews.llvm.org/D116492
2022-01-02 06:29:26 +00:00
# If we are not building as a part of LLVM, build LLD as an
# standalone project, using LLVM as an external library:
build: add support for standalone lld build Enable building lld as a standalone project. This is motivated by the desire to package lld for inclusion in a linux distribution. This allows building lld against an existing paired llvm installation. Now that lld is usable on x86_64, it makes sense to revive this configuration to allow distributions to package it. llvm-svn: 289421
2016-12-12 05:47:40 +00:00
if(CMAKE_SOURCE_DIR STREQUAL CMAKE_CURRENT_SOURCE_DIR)
project(lld)
[cmake] Make include(GNUInstallDirs) always below project(..) Its defaulting logic must go after `project(..)` to work correctly, but `project(..)` is often in a standalone condition making this awkward, since the rest of the condition code may also need GNUInstallDirs. The good thing is there are the various standalone booleans, which I had missed before. This makes splitting the conditional blocks less awkward. Reviewed By: arichardson, phosek, beanz, ldionne, #libunwind, #libc, #libc_abi Differential Revision: https://reviews.llvm.org/D117639
2022-01-19 06:45:07 +00:00
set(LLD_BUILT_STANDALONE TRUE)
endif()
build: add support for standalone lld build Enable building lld as a standalone project. This is motivated by the desire to package lld for inclusion in a linux distribution. This allows building lld against an existing paired llvm installation. Now that lld is usable on x86_64, it makes sense to revive this configuration to allow distributions to package it. llvm-svn: 289421
2016-12-12 05:47:40 +00:00
[cmake] Make include(GNUInstallDirs) always below project(..) Its defaulting logic must go after `project(..)` to work correctly, but `project(..)` is often in a standalone condition making this awkward, since the rest of the condition code may also need GNUInstallDirs. The good thing is there are the various standalone booleans, which I had missed before. This makes splitting the conditional blocks less awkward. Reviewed By: arichardson, phosek, beanz, ldionne, #libunwind, #libc, #libc_abi Differential Revision: https://reviews.llvm.org/D117639
2022-01-19 06:45:07 +00:00
# Must go below project(..)
include(GNUInstallDirs)
if(LLD_BUILT_STANDALONE)
[LLVM] Update C++ standard to 17 Also make the soft toolchain requirements hard. This allows us to use C++17 features in LLVM now. If we find patterns with C++17 that improve readability it should be recommended in the coding standards. Reviewed By: jhenderson, cor3ntin, MaskRay Differential Revision: https://reviews.llvm.org/D130689
2022-08-05 21:45:55 +02:00
set(CMAKE_CXX_STANDARD 17 CACHE STRING "C++ standard to conform to")
[lld] Require C++14 in LLD standalone build This is what the Clang standalone build does too. And setting this seems to be required to get the standalone build to work on my Mac. Reviewed By: #lld-macho, MaskRay, Ericson2314, smeenai Differential Revision: https://reviews.llvm.org/D120269
2022-02-22 18:14:47 -05:00
set(CMAKE_CXX_STANDARD_REQUIRED YES)
set(CMAKE_CXX_EXTENSIONS NO)
build: add support for standalone lld build Enable building lld as a standalone project. This is motivated by the desire to package lld for inclusion in a linux distribution. This allows building lld against an existing paired llvm installation. Now that lld is usable on x86_64, it makes sense to revive this configuration to allow distributions to package it. llvm-svn: 289421
2016-12-12 05:47:40 +00:00
set(CMAKE_INCLUDE_CURRENT_DIR ON)
[lld] Deprecate using llvm-config to detect llvm installation This is continuing in the path of D51714, which did this for Clang. I have rearranged the source code Clang so one can diff the top-level CMakeLists.txt of Clang and LLD, ensuring we use the same strategy for both. Besides diffing the two files, `git diff --color-moved` on LLD also helps review. Reviewed By: beanz Differential Revision: https://reviews.llvm.org/D116492
2022-01-02 06:29:26 +00:00
find_package(LLVM REQUIRED HINTS "${LLVM_CMAKE_DIR}")
[lld][clang][cmake] Clean up a few things - If not using `llvm-config`, `LLVM_MAIN_SRC_DIR` now has a sane default - `LLVM_CONFIG_PATH` will continue to work for LLD for back compat. - More quoting of paths in an abundance of caution. Reviewed By: nikic Differential Revision: https://reviews.llvm.org/D118792
2022-02-02 15:37:13 +00:00
list(APPEND CMAKE_MODULE_PATH "${LLVM_DIR}")
build: add support for standalone lld build Enable building lld as a standalone project. This is motivated by the desire to package lld for inclusion in a linux distribution. This allows building lld against an existing paired llvm installation. Now that lld is usable on x86_64, it makes sense to revive this configuration to allow distributions to package it. llvm-svn: 289421
2016-12-12 05:47:40 +00:00
[lld] Fix comment typos to cycle bots
2023-01-10 10:20:39 -05:00
# Turn into CACHE PATHs for overwriting
lld/cmake: Drop use of llvm-config for LLVM install discovery This has been deprecated since D116492 earlier in 2022. That seems recent, but with the recent cut of LLVM 15 that is still two releases (14 and 15). Meanwhile Clang has deprecated `llvm-config` for a lot longer, and since it is likely that LLD users are also Clang users, this serves as an extra "heads up" that `llvm-config` is on its way out. Remove it in favor of using CMake's find_package() function. Reviewed By: MaskRay, mgorny Differential Revision: https://reviews.llvm.org/D131144
2022-08-06 09:22:19 -04:00
set(LLVM_INCLUDE_DIRS ${LLVM_INCLUDE_DIRS} CACHE PATH "Path to llvm/include and any other header dirs needed")
set(LLVM_BINARY_DIR "${LLVM_BINARY_DIR}" CACHE PATH "Path to LLVM build tree")
set(LLVM_MAIN_SRC_DIR "${CMAKE_CURRENT_SOURCE_DIR}/../llvm" CACHE PATH "Path to LLVM source tree")
build: add support for standalone lld build Enable building lld as a standalone project. This is motivated by the desire to package lld for inclusion in a linux distribution. This allows building lld against an existing paired llvm installation. Now that lld is usable on x86_64, it makes sense to revive this configuration to allow distributions to package it. llvm-svn: 289421
2016-12-12 05:47:40 +00:00
[lld] Deprecate using llvm-config to detect llvm installation This is continuing in the path of D51714, which did this for Clang. I have rearranged the source code Clang so one can diff the top-level CMakeLists.txt of Clang and LLD, ensuring we use the same strategy for both. Besides diffing the two files, `git diff --color-moved` on LLD also helps review. Reviewed By: beanz Differential Revision: https://reviews.llvm.org/D116492
2022-01-02 06:29:26 +00:00
find_program(LLVM_TABLEGEN_EXE "llvm-tblgen" ${LLVM_TOOLS_BINARY_DIR}
NO_DEFAULT_PATH)
build: add support for standalone lld build Enable building lld as a standalone project. This is motivated by the desire to package lld for inclusion in a linux distribution. This allows building lld against an existing paired llvm installation. Now that lld is usable on x86_64, it makes sense to revive this configuration to allow distributions to package it. llvm-svn: 289421
2016-12-12 05:47:40 +00:00
[lld] Deprecate using llvm-config to detect llvm installation This is continuing in the path of D51714, which did this for Clang. I have rearranged the source code Clang so one can diff the top-level CMakeLists.txt of Clang and LLD, ensuring we use the same strategy for both. Besides diffing the two files, `git diff --color-moved` on LLD also helps review. Reviewed By: beanz Differential Revision: https://reviews.llvm.org/D116492
2022-01-02 06:29:26 +00:00
# They are used as destination of target generators.
build: add support for standalone lld build Enable building lld as a standalone project. This is motivated by the desire to package lld for inclusion in a linux distribution. This allows building lld against an existing paired llvm installation. Now that lld is usable on x86_64, it makes sense to revive this configuration to allow distributions to package it. llvm-svn: 289421
2016-12-12 05:47:40 +00:00
set(LLVM_RUNTIME_OUTPUT_INTDIR ${CMAKE_BINARY_DIR}/${CMAKE_CFG_INTDIR}/bin)
Revert "[cmake] Use `CMAKE_INSTALL_LIBDIR` too" This reverts commit f7a33090a91015836497c75f173775392ab0304d. Unfortunately this causes a number of failures that didn't show up in my local build.
2022-08-18 22:44:46 -04:00
set(LLVM_LIBRARY_OUTPUT_INTDIR ${CMAKE_BINARY_DIR}/${CMAKE_CFG_INTDIR}/lib${LLVM_LIBDIR_SUFFIX})
build: add support for standalone lld build Enable building lld as a standalone project. This is motivated by the desire to package lld for inclusion in a linux distribution. This allows building lld against an existing paired llvm installation. Now that lld is usable on x86_64, it makes sense to revive this configuration to allow distributions to package it. llvm-svn: 289421
2016-12-12 05:47:40 +00:00
include(AddLLVM)
include(TableGen)
include(HandleLLVMOptions)
[test] Add ability to get error messages from CMake for errc substitution Visual Studios implementation of the C++ Standard Library does not use strerror to produce a message for std::error_code unlike other standard libraries such as libstdc++ or libc++ that might be used. This patch adds a cmake script that through running a C++ program gets the error messages for the POSIX error codes and passes them onto lit through an optional config parameter. If the config parameter is not set, or getting the messages failed, due to say a cross compiling configuration without an emulator, it will fall back to using pythons strerror functions. Differential Revision: https://reviews.llvm.org/D98278
2021-03-15 20:56:08 +01:00
include(GetErrcMessages)
lld: link libatomic if needed for Timer D80298 made Timer::total atomic, but this requires linking libatomic on some targets. Reviewed By: aaronpuchert Differential Revision: https://reviews.llvm.org/D85691
2020-08-17 15:31:32 -07:00
include(CheckAtomic)
[cmake] Support running tests in stand-alone builds Add the CMake bits necessary to run lld tests (and unittests) when building stand-alone. The code is based on the equivalent code in clang, and includes: 1. checking for Python, searching for lit and necessary LLVM test tools (FileCount and not), 2. building LLVM test tools (FileCount and not) from LLVM sources if they are not installed, 3. building gtest libraries from LLVM sources, 4. adjusting dependencies so that test targets depend only on those LLVM targets that are available for a particular variant of stand-alone build. With this patch, I am able to successfully run 1002 (+10 unsupported) lit tests on Gentoo using installed LLVM. Differential Revision: https://reviews.llvm.org/D28750 llvm-svn: 293630
2017-01-31 14:10:20 +00:00
[lld] Deprecate using llvm-config to detect llvm installation This is continuing in the path of D51714, which did this for Clang. I have rearranged the source code Clang so one can diff the top-level CMakeLists.txt of Clang and LLD, ensuring we use the same strategy for both. Besides diffing the two files, `git diff --color-moved` on LLD also helps review. Reviewed By: beanz Differential Revision: https://reviews.llvm.org/D116492
2022-01-02 06:29:26 +00:00
set(PACKAGE_VERSION "${LLVM_PACKAGE_VERSION}")
[clang][lld][cmake] Simplify header dirs We don't need to recompute the list LLVMConfig.cmake provides us. When LLVM is being built, the list is two elements long: generated headers and headers from source. When LLVM is already built,the list is one element long: the installed header directory containing both generated and hand-written sources. Reviewed By: sebastian-ne Differential Revision: https://reviews.llvm.org/D130553
2022-07-26 07:17:30 +00:00
include_directories(${LLVM_INCLUDE_DIRS})
[lld] Deprecate using llvm-config to detect llvm installation This is continuing in the path of D51714, which did this for Clang. I have rearranged the source code Clang so one can diff the top-level CMakeLists.txt of Clang and LLD, ensuring we use the same strategy for both. Besides diffing the two files, `git diff --color-moved` on LLD also helps review. Reviewed By: beanz Differential Revision: https://reviews.llvm.org/D116492
2022-01-02 06:29:26 +00:00
link_directories(${LLVM_LIBRARY_DIRS})
[cmake] Support running tests in stand-alone builds Add the CMake bits necessary to run lld tests (and unittests) when building stand-alone. The code is based on the equivalent code in clang, and includes: 1. checking for Python, searching for lit and necessary LLVM test tools (FileCount and not), 2. building LLVM test tools (FileCount and not) from LLVM sources if they are not installed, 3. building gtest libraries from LLVM sources, 4. adjusting dependencies so that test targets depend only on those LLVM targets that are available for a particular variant of stand-alone build. With this patch, I am able to successfully run 1002 (+10 unsupported) lit tests on Gentoo using installed LLVM. Differential Revision: https://reviews.llvm.org/D28750 llvm-svn: 293630
2017-01-31 14:10:20 +00:00
if(LLVM_INCLUDE_TESTS)
[CMake] Require python 3.6 if enabling LLVM test targets The lit test suite uses python 3.6 features. Rather than a strange python syntax error upon running the lit tests, we will require the correct version in CMake. Reviewed By: serge-sans-paille, yln Differential Revision: https://reviews.llvm.org/D95635
2021-03-15 09:33:31 -07:00
find_package(Python3 ${LLVM_MINIMUM_PYTHON_VERSION} REQUIRED
COMPONENTS Interpreter)
[cmake] Support running tests in stand-alone builds Add the CMake bits necessary to run lld tests (and unittests) when building stand-alone. The code is based on the equivalent code in clang, and includes: 1. checking for Python, searching for lit and necessary LLVM test tools (FileCount and not), 2. building LLVM test tools (FileCount and not) from LLVM sources if they are not installed, 3. building gtest libraries from LLVM sources, 4. adjusting dependencies so that test targets depend only on those LLVM targets that are available for a particular variant of stand-alone build. With this patch, I am able to successfully run 1002 (+10 unsupported) lit tests on Gentoo using installed LLVM. Differential Revision: https://reviews.llvm.org/D28750 llvm-svn: 293630
2017-01-31 14:10:20 +00:00
# Check prebuilt llvm/utils.
if(EXISTS ${LLVM_TOOLS_BINARY_DIR}/FileCheck${CMAKE_EXECUTABLE_SUFFIX}
AND EXISTS ${LLVM_TOOLS_BINARY_DIR}/not${CMAKE_EXECUTABLE_SUFFIX})
set(LLVM_UTILS_PROVIDED ON)
endif()
if(EXISTS ${LLVM_MAIN_SRC_DIR}/utils/lit/lit.py)
# Note: path not really used, except for checking if lit was found
[lld] respect LLVM_EXTERNAL_LIT Consider a setup without a system-wide installation of lit. Instead you pass the path to lit like this: ``` cmake ... -DLLVM_EXTERNAL_LIT=<PATH_TO_LIT_BINARY> ... ``` Then you will run into this error: ``` ninja: error: unknown target 'check-lld' ``` I have a buildbot builder that fails with this message. Here's the passage that triggers this error: https://github.com/llvm/llvm-zorg/blob/d3bfd5ccbceb542098c350e4d071ceceac6854cb/zorg/buildbot/builders/annotated/standalone-build.sh#L194-L239 By using `LLVM_EXTERNAL_LIT` instead of `LLVM_LIT` we fix this problem. See [here](https://llvm.org/docs/GettingStarted.html#stand-alone-builds) for a description: > Both the LLVM_ROOT and LLVM_EXTERNAL_LIT options are required to do stand-alone builds for all sub-projects. Additional required options for each sub-project can be found in the table below. Differential Revision: https://reviews.llvm.org/D154599
2023-07-06 14:05:02 +02:00
set(LLVM_EXTERNAL_LIT ${LLVM_MAIN_SRC_DIR}/utils/lit/lit.py)
[cmake] Support running tests in stand-alone builds Add the CMake bits necessary to run lld tests (and unittests) when building stand-alone. The code is based on the equivalent code in clang, and includes: 1. checking for Python, searching for lit and necessary LLVM test tools (FileCount and not), 2. building LLVM test tools (FileCount and not) from LLVM sources if they are not installed, 3. building gtest libraries from LLVM sources, 4. adjusting dependencies so that test targets depend only on those LLVM targets that are available for a particular variant of stand-alone build. With this patch, I am able to successfully run 1002 (+10 unsupported) lit tests on Gentoo using installed LLVM. Differential Revision: https://reviews.llvm.org/D28750 llvm-svn: 293630
2017-01-31 14:10:20 +00:00
if(NOT LLVM_UTILS_PROVIDED)
add_subdirectory(${LLVM_MAIN_SRC_DIR}/utils/FileCheck utils/FileCheck)
add_subdirectory(${LLVM_MAIN_SRC_DIR}/utils/not utils/not)
set(LLVM_UTILS_PROVIDED ON)
set(LLD_TEST_DEPS FileCheck not)
endif()
[lld] Use installed llvm_gtest in standalone builds Use the installed llvm_gtest library instead of rebuilding it locally when standalone builds are used. This change is now required as otherwise the build fails due to duplicate llvm_gtest target. This is based on 82169103958583d3320b3a9a1e6542e8d32ef8da in clang. Differential Revision: https://reviews.llvm.org/D145964
2023-03-13 18:22:31 +01:00
if (NOT TARGET llvm_gtest)
message(FATAL_ERROR "llvm-gtest not found. Please install llvm-gtest or disable tests with -DLLVM_INCLUDE_TESTS=OFF")
[cmake] Support running tests in stand-alone builds Add the CMake bits necessary to run lld tests (and unittests) when building stand-alone. The code is based on the equivalent code in clang, and includes: 1. checking for Python, searching for lit and necessary LLVM test tools (FileCount and not), 2. building LLVM test tools (FileCount and not) from LLVM sources if they are not installed, 3. building gtest libraries from LLVM sources, 4. adjusting dependencies so that test targets depend only on those LLVM targets that are available for a particular variant of stand-alone build. With this patch, I am able to successfully run 1002 (+10 unsupported) lit tests on Gentoo using installed LLVM. Differential Revision: https://reviews.llvm.org/D28750 llvm-svn: 293630
2017-01-31 14:10:20 +00:00
endif()
else()
# Seek installed Lit.
[lld] respect LLVM_EXTERNAL_LIT Consider a setup without a system-wide installation of lit. Instead you pass the path to lit like this: ``` cmake ... -DLLVM_EXTERNAL_LIT=<PATH_TO_LIT_BINARY> ... ``` Then you will run into this error: ``` ninja: error: unknown target 'check-lld' ``` I have a buildbot builder that fails with this message. Here's the passage that triggers this error: https://github.com/llvm/llvm-zorg/blob/d3bfd5ccbceb542098c350e4d071ceceac6854cb/zorg/buildbot/builders/annotated/standalone-build.sh#L194-L239 By using `LLVM_EXTERNAL_LIT` instead of `LLVM_LIT` we fix this problem. See [here](https://llvm.org/docs/GettingStarted.html#stand-alone-builds) for a description: > Both the LLVM_ROOT and LLVM_EXTERNAL_LIT options are required to do stand-alone builds for all sub-projects. Additional required options for each sub-project can be found in the table below. Differential Revision: https://reviews.llvm.org/D154599
2023-07-06 14:05:02 +02:00
find_program(LLVM_EXTERNAL_LIT
[cmake] Support running tests in stand-alone builds Add the CMake bits necessary to run lld tests (and unittests) when building stand-alone. The code is based on the equivalent code in clang, and includes: 1. checking for Python, searching for lit and necessary LLVM test tools (FileCount and not), 2. building LLVM test tools (FileCount and not) from LLVM sources if they are not installed, 3. building gtest libraries from LLVM sources, 4. adjusting dependencies so that test targets depend only on those LLVM targets that are available for a particular variant of stand-alone build. With this patch, I am able to successfully run 1002 (+10 unsupported) lit tests on Gentoo using installed LLVM. Differential Revision: https://reviews.llvm.org/D28750 llvm-svn: 293630
2017-01-31 14:10:20 +00:00
NAMES llvm-lit lit.py lit
PATHS "${LLVM_MAIN_SRC_DIR}/utils/lit"
DOC "Path to lit.py")
endif()
[lld] respect LLVM_EXTERNAL_LIT Consider a setup without a system-wide installation of lit. Instead you pass the path to lit like this: ``` cmake ... -DLLVM_EXTERNAL_LIT=<PATH_TO_LIT_BINARY> ... ``` Then you will run into this error: ``` ninja: error: unknown target 'check-lld' ``` I have a buildbot builder that fails with this message. Here's the passage that triggers this error: https://github.com/llvm/llvm-zorg/blob/d3bfd5ccbceb542098c350e4d071ceceac6854cb/zorg/buildbot/builders/annotated/standalone-build.sh#L194-L239 By using `LLVM_EXTERNAL_LIT` instead of `LLVM_LIT` we fix this problem. See [here](https://llvm.org/docs/GettingStarted.html#stand-alone-builds) for a description: > Both the LLVM_ROOT and LLVM_EXTERNAL_LIT options are required to do stand-alone builds for all sub-projects. Additional required options for each sub-project can be found in the table below. Differential Revision: https://reviews.llvm.org/D154599
2023-07-06 14:05:02 +02:00
if(LLVM_EXTERNAL_LIT)
[cmake] Support running tests in stand-alone builds Add the CMake bits necessary to run lld tests (and unittests) when building stand-alone. The code is based on the equivalent code in clang, and includes: 1. checking for Python, searching for lit and necessary LLVM test tools (FileCount and not), 2. building LLVM test tools (FileCount and not) from LLVM sources if they are not installed, 3. building gtest libraries from LLVM sources, 4. adjusting dependencies so that test targets depend only on those LLVM targets that are available for a particular variant of stand-alone build. With this patch, I am able to successfully run 1002 (+10 unsupported) lit tests on Gentoo using installed LLVM. Differential Revision: https://reviews.llvm.org/D28750 llvm-svn: 293630
2017-01-31 14:10:20 +00:00
# Define the default arguments to use with 'lit', and an option for the user
# to override.
set(LIT_ARGS_DEFAULT "-sv")
if (MSVC OR XCODE)
set(LIT_ARGS_DEFAULT "${LIT_ARGS_DEFAULT} --no-progress-bar")
endif()
set(LLVM_LIT_ARGS "${LIT_ARGS_DEFAULT}" CACHE STRING "Default options for lit")
[test] Add ability to get error messages from CMake for errc substitution Visual Studios implementation of the C++ Standard Library does not use strerror to produce a message for std::error_code unlike other standard libraries such as libstdc++ or libc++ that might be used. This patch adds a cmake script that through running a C++ program gets the error messages for the POSIX error codes and passes them onto lit through an optional config parameter. If the config parameter is not set, or getting the messages failed, due to say a cross compiling configuration without an emulator, it will fall back to using pythons strerror functions. Differential Revision: https://reviews.llvm.org/D98278
2021-03-15 20:56:08 +01:00
get_errc_messages(LLVM_LIT_ERRC_MESSAGES)
[cmake] Support running tests in stand-alone builds Add the CMake bits necessary to run lld tests (and unittests) when building stand-alone. The code is based on the equivalent code in clang, and includes: 1. checking for Python, searching for lit and necessary LLVM test tools (FileCount and not), 2. building LLVM test tools (FileCount and not) from LLVM sources if they are not installed, 3. building gtest libraries from LLVM sources, 4. adjusting dependencies so that test targets depend only on those LLVM targets that are available for a particular variant of stand-alone build. With this patch, I am able to successfully run 1002 (+10 unsupported) lit tests on Gentoo using installed LLVM. Differential Revision: https://reviews.llvm.org/D28750 llvm-svn: 293630
2017-01-31 14:10:20 +00:00
# On Win32 hosts, provide an option to specify the path to the GnuWin32 tools.
if(WIN32 AND NOT CYGWIN)
set(LLVM_LIT_TOOLS_DIR "" CACHE PATH "Path to GnuWin32 tools")
endif()
else()
set(LLVM_INCLUDE_TESTS OFF)
endif()
endif()
[lld] Deprecate using llvm-config to detect llvm installation This is continuing in the path of D51714, which did this for Clang. I have rearranged the source code Clang so one can diff the top-level CMakeLists.txt of Clang and LLD, ensuring we use the same strategy for both. Besides diffing the two files, `git diff --color-moved` on LLD also helps review. Reviewed By: beanz Differential Revision: https://reviews.llvm.org/D116492
2022-01-02 06:29:26 +00:00
endif() # standalone
build: add support for standalone lld build Enable building lld as a standalone project. This is motivated by the desire to package lld for inclusion in a linux distribution. This allows building lld against an existing paired llvm installation. Now that lld is usable on x86_64, it makes sense to revive this configuration to allow distributions to package it. llvm-svn: 289421
2016-12-12 05:47:40 +00:00
[cmake] Don't export `LLVM_TOOLS_INSTALL_DIR` anymore First of all, `LLVM_TOOLS_INSTALL_DIR` put there breaks our NixOS builds, because `LLVM_TOOLS_INSTALL_DIR` defined the same as `CMAKE_INSTALL_BINDIR` becomes an *absolute* path, and then when downstream projects try to install there too this breaks because our builds always install to fresh directories for isolation's sake. Second of all, note that `LLVM_TOOLS_INSTALL_DIR` stands out against the other specially crafted `LLVM_CONFIG_*` variables substituted in `llvm/cmake/modules/LLVMConfig.cmake.in`. @beanz added it in d0e1c2a550ef348aae036d0fe78cab6f038c420c to fix a dangling reference in `AddLLVM`, but I am suspicious of how this variable doesn't follow the pattern. Those other ones are carefully made to be build-time vs install-time variables depending on which `LLVMConfig.cmake` is being generated, are carefully made relative as appropriate, etc. etc. For my NixOS use-case they are also fine because they are never used as downstream install variables, only for reading not writing. To avoid the problems I face, and restore symmetry, I deleted the exported and arranged to have many `${project}_TOOLS_INSTALL_DIR`s. `AddLLVM` now instead expects each project to define its own, and they do so based on `CMAKE_INSTALL_BINDIR`. `LLVMConfig` still exports `LLVM_TOOLS_BINARY_DIR` which is the location for the tools defined in the usual way, matching the other remaining exported variables. For the `AddLLVM` changes, I tried to copy the existing pattern of internal vs non-internal or for LLVM vs for downstream function/macro names, but it would good to confirm I did that correctly. Reviewed By: nikic Differential Revision: https://reviews.llvm.org/D117977
2022-06-11 06:11:59 +00:00
set(LLD_TOOLS_INSTALL_DIR "${CMAKE_INSTALL_BINDIR}" CACHE PATH
"Path for binary subdirectory (defaults to '${CMAKE_INSTALL_BINDIR}')")
mark_as_advanced(LLD_TOOLS_INSTALL_DIR)
Initial commit. Code by Nick Kledzik. Cleanups and build system by me. llvm-svn: 146844
2011-12-18 08:27:59 +00:00
set(LLD_SOURCE_DIR ${CMAKE_CURRENT_SOURCE_DIR})
Set CMake ADDITIONAL_HEADER_DIRS on libraries with headers in /include. NFC. In a UI such as XCode, it can group the headers for a library with that library. This is done in the CMakeLists.txt for the library itself by setting the path(s) as ADDITIONAL_HEADER_DIRS. LLVM already does this for all of its libraries, so just adding this to lld to make things easier. Should be NFC. llvm-svn: 257002
2016-01-07 00:14:09 +00:00
set(LLD_INCLUDE_DIR ${LLD_SOURCE_DIR}/include )
Initial commit. Code by Nick Kledzik. Cleanups and build system by me. llvm-svn: 146844
2011-12-18 08:27:59 +00:00
set(LLD_BINARY_DIR ${CMAKE_CURRENT_BINARY_DIR})
Add vendor macro to "lld" Summary: Add the vendor macro to "lld" for extended version output support, such that it's able to print additional version info. This is consistent with the Clang and LLVM version printer, and the additional version message can be provided via PACKAGE_VENDOR. Reviewers: hubert.reinterpretcast, kbarton, cebowleratibm, rzurob, ruiu Reviewed By: hubert.reinterpretcast Subscribers: emaste, mgorny, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D79026
2020-05-11 18:33:55 -04:00
set(LLD_VENDOR ${PACKAGE_VENDOR} CACHE STRING
"Vendor-specific text for showing with version information.")
if(LLD_VENDOR)
add_definitions(-DLLD_VENDOR="${LLD_VENDOR}")
endif()
Add support to print version. Summary: Add support in the universal driver to print the lld version and the repository version. Test Plan: A driver test is added Reviewers: kledzik, ruiu Reviewed By: ruiu Subscribers: llvm-commits Projects: #lld Differential Revision: http://reviews.llvm.org/D5641 llvm-svn: 219277
2014-10-08 03:47:51 +00:00
# Compute the LLD version from the LLVM version.
string(REGEX MATCH "[0-9]+\\.[0-9]+(\\.[0-9]+)?" LLD_VERSION
${PACKAGE_VERSION})
message(STATUS "LLD version: ${LLD_VERSION}")
string(REGEX REPLACE "([0-9]+)\\.[0-9]+(\\.[0-9]+)?" "\\1" LLD_VERSION_MAJOR
${LLD_VERSION})
string(REGEX REPLACE "[0-9]+\\.([0-9]+)(\\.[0-9]+)?" "\\1" LLD_VERSION_MINOR
${LLD_VERSION})
try to unbreak build after 4b6d9ac392613
2020-01-16 10:12:06 -05:00
# Configure the Version.inc file.
configure_file(
${CMAKE_CURRENT_SOURCE_DIR}/include/lld/Common/Version.inc.in
${CMAKE_CURRENT_BINARY_DIR}/include/lld/Common/Version.inc)
Initial commit. Code by Nick Kledzik. Cleanups and build system by me. llvm-svn: 146844
2011-12-18 08:27:59 +00:00
if (CMAKE_SOURCE_DIR STREQUAL CMAKE_BINARY_DIR)
message(FATAL_ERROR "In-source builds are not allowed. CMake would overwrite "
"the makefiles distributed with LLVM. Please create a directory and run cmake "
"from there, passing the path to this source directory as the last argument. "
"This process created the file `CMakeCache.txt' and the directory "
"`CMakeFiles'. Please delete them.")
endif()
[lld][CMake] Use `GNUInstallDirs` to support custom installation dirs Extracted from D99484. My new plan is to start from the outside and work inward. Reviewed By: stephenneuendorffer Differential Revision: https://reviews.llvm.org/D115568
2021-12-30 06:22:48 +00:00
# Add path for custom modules.
list(INSERT CMAKE_MODULE_PATH 0
"${LLD_SOURCE_DIR}/cmake/modules"
Set the path to the shared cmake modules based on the llvm directory It’s still possible to build parts of the main llvm build (lld, clang etc) by symlinking them into llvm/tools. Reviewed By: Ericson2314 Differential Revision: https://reviews.llvm.org/D116472
2022-01-01 17:51:16 +00:00
"${LLVM_COMMON_CMAKE_UTILS}/Modules"
[lld][CMake] Use `GNUInstallDirs` to support custom installation dirs Extracted from D99484. My new plan is to start from the outside and work inward. Reviewed By: stephenneuendorffer Differential Revision: https://reviews.llvm.org/D115568
2021-12-30 06:22:48 +00:00
)
Add VTune as an optional external dependency and add task tracking. llvm-svn: 178940
2013-04-06 00:56:40 +00:00
[CMake] Add install target for the lld tool This is necessary for the distribution targets which assume that each component has an install target. This also moves the CMake macros into a separate file akin to other LLVM projects. Differential Revision: https://reviews.llvm.org/D27876 llvm-svn: 290391
2016-12-23 00:22:47 +00:00
include(AddLLD)
Add VTune as an optional external dependency and add task tracking. llvm-svn: 178940
2013-04-06 00:56:40 +00:00
option(LLD_USE_VTUNE
"Enable VTune user task tracking."
OFF)
if (LLD_USE_VTUNE)
find_package(VTune)
if (VTUNE_FOUND)
include_directories(${VTune_INCLUDE_DIRS})
list(APPEND LLVM_COMMON_LIBS ${VTune_LIBRARIES})
add_definitions(-DLLD_HAS_VTUNE)
endif()
endif()
[CMake] Add install target for the lld tool This is necessary for the distribution targets which assume that each component has an install target. This also moves the CMake macros into a separate file akin to other LLVM projects. Differential Revision: https://reviews.llvm.org/D27876 llvm-svn: 290391
2016-12-23 00:22:47 +00:00
option(LLD_BUILD_TOOLS
"Build the lld tools. If OFF, just generate build targets." ON)
Sources now require C++11 to build. Add first linker pass (StubsPass) which looks for calls to shared library symbols and replaces them with calls to a StubAtom. On ELF system, a "stub" is a PLT entry. Added a simple test case. Pass a Platform object to YAML reader and writer for converting fixup kinds between names and values. Change output of Resolver to be a File object instead of a vector of Atoms. Thus, passes operate on a File instead of just Atoms. Rework how to walk through a File's Atoms. Now iterator based instead of a method that visits each atom. llvm-svn: 152269
2012-03-08 00:18:30 +00:00
[LLD] Allow configuring default ld.lld backend The motivation for this is ld.lld --help targeting MinGW which currently prints help for the ELF backend unless -m i386pe{,p} is added. This confuses build systems that grep through linker help to find supported flags. This matches LD from Binutils which always prints help for MinGW when configured to target it. After this change, the backend can still be overridden to any supported ELF/MinGW target by using correct -m <arch>. Differential Revision: https://reviews.llvm.org/D87418
2020-09-15 08:39:15 +03:00
option(LLD_DEFAULT_LD_LLD_IS_MINGW
"Use MinGW as the default backend for ld.lld. If OFF, ELF will be used." OFF)
if (LLD_DEFAULT_LD_LLD_IS_MINGW)
add_definitions("-DLLD_DEFAULT_LD_LLD_IS_MINGW=1")
endif()
Disable warning 4530 for MSVC builds. We compile with exceptions off for LLVM and all other LLVM subprojects, so this brings parity to LLD and disables this warning. Reviewed by: Rui Ueyama llvm-svn: 223131
2014-12-02 17:57:54 +00:00
if (MSVC)
add_definitions(-wd4530) # Suppress 'warning C4530: C++ exception handler used, but unwind semantics are not enabled.'
Suppress 'warning C4062: enumerator X in switch of enum Y is not handled' from system header. llvm-svn: 230422
2015-02-25 01:30:13 +00:00
add_definitions(-wd4062) # Suppress 'warning C4062: enumerator X in switch of enum Y is not handled' from system header.
Disable warning 4530 for MSVC builds. We compile with exceptions off for LLVM and all other LLVM subprojects, so this brings parity to LLD and disables this warning. Reviewed by: Rui Ueyama llvm-svn: 223131
2014-12-02 17:57:54 +00:00
endif()
Initial commit. Code by Nick Kledzik. Cleanups and build system by me. llvm-svn: 146844
2011-12-18 08:27:59 +00:00
include_directories(BEFORE
${CMAKE_CURRENT_BINARY_DIR}/include
${CMAKE_CURRENT_SOURCE_DIR}/include
)
Move new lld's code to Common subdirectory. New lld's files are spread under lib subdirectory, and it isn't easy to find which files are actually maintained. This patch moves maintained files to Common subdirectory. Differential Revision: https://reviews.llvm.org/D37645 llvm-svn: 314719
2017-10-02 21:00:41 +00:00
add_subdirectory(Common)
Inline a trivial CMakeLists.txt. llvm-svn: 262574
2016-03-03 01:56:23 +00:00
add_subdirectory(tools/lld)
Initial commit. Code by Nick Kledzik. Cleanups and build system by me. llvm-svn: 146844
2011-12-18 08:27:59 +00:00
Remove CMake standalone build configuration Differential Revision: http://reviews.llvm.org/D6898 llvm-svn: 225704
2015-01-12 21:41:10 +00:00
if (LLVM_INCLUDE_TESTS)
Re-land [LLD] Allow usage of LLD as a library This reverts commit aa495214b39d475bab24b468de7a7c676ce9e366. As discussed in https://github.com/llvm/llvm-project/issues/53475 this patch allows for using LLD-as-a-lib. It also lets clients link only the drivers that they want (see unit tests). This also adds the unit test infra as in the other LLVM projects. Among the test coverage, I've added the original issue from @krzysz00, see: https://github.com/ROCmSoftwarePlatform/D108850-lld-bug-reproduction Important note: this doesn't allow (yet) linking in parallel. This will come a bit later hopefully, in subsequent patches, for COFF at least. Differential revision: https://reviews.llvm.org/D119049
2023-06-19 07:32:34 -04:00
add_custom_target(LLDUnitTests)
[lld] Revise IDE folder structure (#89747) Update the folder titles for targets in the monorepository that have not seen taken care of for some time. These are the folders that targets are organized in Visual Studio and XCode (`set_property(TARGET <target> PROPERTY FOLDER "<title>")`) when using the respective CMake's IDE generator. * Ensure that every target is in a folder * Use a folder hierarchy with each LLVM subproject as a top-level folder * Use consistent folder names between subprojects * When using target-creating functions from AddLLVM.cmake, automatically deduce the folder. This reduces the number of `set_property`/`set_target_property`, but are still necessary when `add_custom_target`, `add_executable`, `add_library`, etc. are used. A LLVM_SUBPROJECT_TITLE definition is used for that in each subproject's root CMakeLists.txt.
2024-06-04 01:31:36 +02:00
set_target_properties(LLDUnitTests PROPERTIES FOLDER "LLD/Tests")
[lld] Fixes for unitests in standalone builds (#83670) 1. Replace the obsolete `llvm_add_unittests()` CMake function with an explicit check for `TARGET llvm_gtest`. This is more consistent with the rest of the code, and it makes it possible to avoid checking out `third-party` tree. 2. Add `LLDUnitTests` test dependency to standalone builds. It is defined unconditionally, and actually necessary to ensure that unit tests will be built.
2024-03-02 20:08:44 +01:00
if (TARGET llvm_gtest)
add_subdirectory(unittests)
endif()
[CMake] Don't include the lld test directory if LLVM_INCLUDE_TESTS is Off This matches the behavior of LLVM and Clang. llvm-svn: 249050
2015-10-01 18:17:47 +00:00
add_subdirectory(test)
[Core][ErrorOr] Add support for user error data. llvm-svn: 170483
2012-12-19 00:51:07 +00:00
endif()
Add support for building Sphinx documentation when being built inside LLVM source tree and using CMake. Patch by Dan Liew <daniel.liew@imperial.ac.uk>! llvm-svn: 206662
2014-04-18 21:59:05 +00:00
add_subdirectory(docs)
COFF: Add a new PE/COFF port. This is an initial patch for a section-based COFF linker. The patch has 2300 lines of code including comments and blank lines. Before diving into details, you want to start from reading README because it should give you an overview of the design. All important things are written in the README file, so I write summary here. - The linker is already able to self-link on Windows. - It's significantly faster than the existing implementation. The existing one takes 5 seconds to link LLD on my machine, while the new one only takes 1.2 seconds, even though the new one is not multi-threaded yet. (And a proof-of-concept multi- threaded version was able to link it in 0.5 seconds.) - It uses much less memory (250MB vs. 2GB virtual memory space to self-host). - IMHO the new code is much simpler and easier to read than the existing PE/COFF port. http://reviews.llvm.org/D10036 llvm-svn: 238458
2015-05-28 19:09:30 +00:00
add_subdirectory(COFF)
[ELF2] Add a new ELF linker based on the new PE/COFF linker. Differential Revision: http://reviews.llvm.org/D11188 llvm-svn: 243161
2015-07-24 21:03:07 +00:00
add_subdirectory(ELF)
Reland D75382 "[lld] Initial commit for new Mach-O backend" With a fix for http://lab.llvm.org:8011/builders/clang-cmake-armv8-lld/builds/3636 Also trims some unneeded dependencies.
2020-04-02 11:54:05 -07:00
add_subdirectory(MachO)
LLD: Introduce a GNU LD style driver for COFF When building COFF programs many targets such as mingw prefer to have a gnu ld frontend. Rather then having a fully fledged standalone driver we wrap a shim around the LINK driver. Extra tests were provided by mstorsjo Reviewers: mstorsjo, ruiu Differential Revision: https://reviews.llvm.org/D33880 llvm-svn: 312926
2017-09-11 17:02:59 +00:00
add_subdirectory(MinGW)
[WebAssembly] Initial wasm linker implementation This linker backend is still a work in progress but is enough to link simple programs including linking against library archives. Differential Revision: https://reviews.llvm.org/D34851 llvm-svn: 318539
2017-11-17 18:14:09 +00:00
add_subdirectory(wasm)
lld: Let find_package(LLD) work Install a cmake config file. Copied exactly from how clang exports. I also wasn't sure whether the canonical capitalization is "lld" or "LLD". The project() is still calling this lld, but most places seemed to capitalize it.
2020-05-02 18:32:40 -04:00
[lld] enable installing lld headers and libraries as part of distribution (#127123) This patch allows `lld-headers` and `lld-libraries` in `LLVM_DISTRIBUTION_COMPONENTS` to be specified and thus enable piecewise installation of `lld/**/*.h` headers and/or lld libraries (both in shared and static builds). This is similar to use cases such as `clang;clang-headers;clang-libraries`. Note when `lld-libraries` is present, `llvm-libraries` must be present as well because various lld libraries depend on various llvm libraries.
2025-02-16 14:18:09 -06:00
add_custom_target(lld-headers)
set_target_properties(lld-headers PROPERTIES FOLDER "Misc")
if (NOT LLVM_INSTALL_TOOLCHAIN_ONLY)
install(DIRECTORY include/lld
DESTINATION "${CMAKE_INSTALL_INCLUDEDIR}"
COMPONENT lld-headers
FILES_MATCHING
PATTERN "*.h"
[lld,CMake] Include Version.inc when LLVM_DISTRIBUTION_COMPONENTS contains lld-headers (#127946) Without this inc file `getLLDVersion` cannot be called; see https://github.com/llvm/llvm-project/blob/main/lld/include/lld/Common/Version.h#L16. Fixes incomplete solution introduced by https://github.com/llvm/llvm-project/pull/127123.
2025-02-21 11:06:33 -06:00
PATTERN "*.inc"
[lld] enable installing lld headers and libraries as part of distribution (#127123) This patch allows `lld-headers` and `lld-libraries` in `LLVM_DISTRIBUTION_COMPONENTS` to be specified and thus enable piecewise installation of `lld/**/*.h` headers and/or lld libraries (both in shared and static builds). This is similar to use cases such as `clang;clang-headers;clang-libraries`. Note when `lld-libraries` is present, `llvm-libraries` must be present as well because various lld libraries depend on various llvm libraries.
2025-02-16 14:18:09 -06:00
)
if (NOT LLVM_ENABLE_IDE)
add_llvm_install_targets(install-lld-headers
DEPENDS lld-headers
COMPONENT lld-headers)
endif()
endif()
# Custom target to install all lld libraries
add_custom_target(lld-libraries)
if (NOT LLVM_ENABLE_IDE)
add_llvm_install_targets(install-lld-libraries
DEPENDS lld-libraries
COMPONENT lld-libraries)
endif()
get_property(LLD_LIBS GLOBAL PROPERTY LLD_ALL_LIBS)
if(LLD_LIBS)
list(REMOVE_DUPLICATES LLD_LIBS)
foreach(lib ${LLD_LIBS})
add_dependencies(lld-libraries ${lib})
if(NOT LLVM_ENABLE_IDE)
add_dependencies(install-lld-libraries install-${lib})
add_dependencies(install-lld-libraries-stripped install-${lib}-stripped)
endif()
endforeach()
endif()
lld: Let find_package(LLD) work Install a cmake config file. Copied exactly from how clang exports. I also wasn't sure whether the canonical capitalization is "lld" or "LLD". The project() is still calling this lld, but most places seemed to capitalize it.
2020-05-02 18:32:40 -04:00
add_subdirectory(cmake/modules)
Reference in New Issue Copy Permalink