aboutsummaryrefslogtreecommitdiff
path: root/cmake
AgeCommit message (Collapse)AuthorFilesLines
2024-03-22Get the linker version and pass the it to compiler-rt tests on Darwin. (#86220)Usama Hameed1-0/+19
The HOST_LINK_VERSION is a hardcoded string in Darwin clang that detects the linker version at configure time. The driver uses this information to build the correct set of arguments for the linker. This patch detects the linker version again during compiler-rt configuration and passes it to the tests. This allows a clang built on a machine with a new linker to run compiler-rt tests on a machine with an old linker. rdar://125198603
2024-03-12[CMake] Fix a typo in 23ffb2bdb96cf5a8eebce86b1ab21acf88979661Martin Storsjö1-3/+3
2024-03-12[CMake] Enable new policy for CMAKE_MSVC_DEBUG_INFORMATION_FORMAT (#82371)Dave Abrahams1-0/+13
2024-03-11[cmake] Exposes LLVM version number in the runtimes. (#84641)Mark de Wever1-0/+15
This allows sharing the LLVM version number in libc++.
2023-07-17[CMake] Switch the CMP0091 policy (MSVC_RUNTIME_LIBRARY) to the new behaviourMartin Storsjö1-5/+0
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
2023-07-05GetClangResourceDir: Fix downstream projects that bundle llvm sourceTom Stellard1-1/+3
A project that bundles the llvm source code may have their own PACKAGE_VERSION variable, so only use this to compute the CLANG_RESOURCE_DIR if CLANG_VERSION_MAJOR is undefined. Reviewed By: sebastian-ne Differential Revision: https://reviews.llvm.org/D152608
2023-06-03[CMake] Ensure `CLANG_RESOURCE_DIR` is respected.paperchalice1-0/+27
re-commit of 39aa0f5c434b463520ac39a8dbe933ee8c4c5ea7 with missing file: cmake/Modules/GetClangResourceDir.cmake.
2023-05-27Reland "[CMake] Bumps minimum version to 3.20.0.Mark de Wever1-0/+5
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-17Revert "Reland "[CMake] Bumps minimum version to 3.20.0.""Nico Weber1-5/+0
This reverts commit 65429b9af6a2c99d340ab2dcddd41dab201f399c. Broke several projects, see https://reviews.llvm.org/D144509#4347562 onwards. Also reverts follow-up commit "[OpenMP] Compile assembly files as ASM, not C" This reverts commit 4072c8aee4c89c4457f4f30d01dc9bb4dfa52559. Also reverts fix attempt "[cmake] Set CMP0091 to fix Windows builds after the cmake_minimum_required bump" This reverts commit 7d47dac5f828efd1d378ba44a97559114f00fb64.
2023-05-16[cmake] Set CMP0091 to fix Windows builds after the cmake_minimum_required bumpHans Wennborg1-0/+5
The build uses other mechanism to select the runtime. Fixes #62719 Differential revision: https://reviews.llvm.org/D150688
2023-05-04[CMake] Install FindLibEdit find moduleEric Kilmer1-66/+0
This is a follow-up to D147153 and addresses CMake warnings about not finding LibEdit find module when another project uses LLVM as a dependency. Fixes https://github.com/llvm/llvm-project/issues/62300 Reviewed By: Dinistro Differential Revision: https://reviews.llvm.org/D148993
2023-03-28Revert "[CMake] Unify llvm_check_linker_flag and ↵Petr Hosek1-17/+24
llvm_check_compiler_linker_flag" This reverts commit 55e65ad876e3ac0b1cb0410a5cce3554c009af65.
2023-03-28[CMake] Unify llvm_check_linker_flag and llvm_check_compiler_linker_flagPetr Hosek1-24/+17
These will be replaced by CMake's check_linker_flag once we update the minimum CMake version 3.20. Differential Revision: https://reviews.llvm.org/D145716
2023-03-12Revert "[CMake] Unify llvm_check_linker_flag and ↵Igor Zhukov1-17/+24
llvm_check_compiler_linker_flag" libc++ clang-cl tests failed after that commit Look at https://buildkite.com/llvm-project/libcxx-ci/builds/20490 Reviewed By: #libc Differential Revision: https://reviews.llvm.org/D145858 This reverts commit b00aaab730ae8bd7f8a44e1808e668e20c2c9282.
2023-03-10[CMake] Unify llvm_check_linker_flag and llvm_check_compiler_linker_flagPetr Hosek1-24/+17
These will be replaced by CMake's check_linker_flag once we update the minimum CMake version 3.20. Differential Revision: https://reviews.llvm.org/D145716
2023-02-22Revert "[CMake] Unify llvm_check_linker_flag and ↵Petr Hosek2-28/+35
llvm_check_compiler_linker_flag" This reverts commit efae3174f09560353fb0f3d528bcbffe060d5438 since it broke the standalone Flang build.
2023-02-22[CMake] Unify llvm_check_linker_flag and llvm_check_compiler_linker_flagPetr Hosek2-35/+28
These have the same purposes but two different implementations. llvm_check_compiler_linker_flag uses CMAKE_REQUIRED_FLAGS which affects flags used both for compilation and linking which is problematic because some flags may be link-only and trigger unused argument warning when set during compilation. llvm_check_linker_flag does not have this issue so we chose it as the prevailaing implementation. Differential Revision: https://reviews.llvm.org/D143052
2023-01-12Revert "build: with -DCLANGD_ENABLE_REMOTE=ON, search for grpc++ ↵Kadir Cetinkaya1-17/+0
dependencies too" This reverts commit 9f3081dc6fe8447e85741865846840bc491866e5. Broke clangd buildbots in https://lab.llvm.org/buildbot/#/builders/131/builds/38935.
2023-01-10build: with -DCLANGD_ENABLE_REMOTE=ON, search for grpc++ dependencies tooSylvestre Ledru1-0/+17
Fixes: https://github.com/llvm/llvm-project/issues/59844 Differential Revision: https://reviews.llvm.org/D141047
2022-11-07[cmake] Add missing CMakePushCheckState include to FindLibEdit.cmakeMichał Górny1-0/+1
Add the missing include to fix an error when `cmake_push_check_state()` is called and incidentally the CMakePushCheckState module is not loaded by any other check running prior to `FindLibEdit.cmake`: CMake Error at /var/no-tmpfs/portage/dev-util/lldb-15.0.4/work/cmake/Modules/FindLibEdit.cmake:24 (cmake_push_check_state): Unknown CMake command "cmake_push_check_state". Call Stack (most recent call first): cmake/modules/LLDBConfig.cmake:52 (find_package) cmake/modules/LLDBConfig.cmake:59 (add_optional_dependency) CMakeLists.txt:28 (include) Gentoo Bug: https://bugs.gentoo.org/880065 Differential Revision: https://reviews.llvm.org/D137555
2022-10-28Harmonize cmake_policy() across standalone builds of all projectsMichał Górny1-0/+12
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-27Revert "Harmonize cmake_policy() across standalone builds of all projects"Michał Górny1-12/+0
This reverts commit 88d7508dc479210f07abccb17f0194b66264b125. It's reported to break builds when symlinking other projects inside the `tools` directory.
2022-10-27Harmonize cmake_policy() across standalone builds of all projectsMichał Górny1-0/+12
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-12[CMake] Fix FindGRPC cmake module to allow different layeringSteven Wu1-0/+155
Take the library target out of `generate_protos` function so the caller can decide where to layer the library using the source generated from the function. Fixes: https://github.com/llvm/llvm-project/issues/58075 Reviewed By: sammccall Differential Revision: https://reviews.llvm.org/D135712
2022-08-18Revert "[cmake] Use `CMAKE_INSTALL_LIBDIR` too"John Ericson1-1/+1
This reverts commit f7a33090a91015836497c75f173775392ab0304d. Unfortunately this causes a number of failures that didn't show up in my local build.
2022-08-18[cmake] Use `CMAKE_INSTALL_LIBDIR` tooJohn Ericson1-1/+1
We held off on this before as `LLVM_LIBDIR_SUFFIX` conflicted with it. Now we return this. `LLVM_LIBDIR_SUFFIX` is kept as a deprecated way to set `CMAKE_INSTALL_LIBDIR`. The other `*_LIBDIR_SUFFIX` are just removed entirely. I imagine this is too potentially-breaking to make LLVM 15. That's fine. I have a more minimal version of this in the disto (NixOS) patches for LLVM 15 (like previous versions). This more expansive version I will test harder after the release is cut. Reviewed By: sebastian-ne, ldionne, #libc, #libc_abi Differential Revision: https://reviews.llvm.org/D130586
2022-07-26[cmake] Fix missing paren in `FindPrefixFromConfig`John Ericson1-1/+1
This was in CMake syntax generation, so we didn't catch it eval time. Follow up from D117973
2022-07-25[cmake] Support custom package install pathsJohn Ericson2-10/+55
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
2022-05-27[CMake] Make FindLibEdit.cmake more robustTobias Ribizel1-37/+32
FindLibEdit uses pkg-config to find the necessary flags, but this may break with cross-compilation, because the PkgConfig module in CMake doesn't respect the SYSROOT specified in a toolchain file. Instead of taking the parameters from pkg-config for granted, we check whether our compiler can actually include and link against the library. Fixes #55445 Fixes #55671 Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D126450
2022-05-16[runtimes] Generalize how we reorder projectsLouis Dionne1-0/+25
This way, we could use it for LLVM_ENABLE_PROJECTS too if desired. Differential Revision: https://reviews.llvm.org/D125121
2022-05-12[llvm][lldb] use FindLibEdit.cmake everywhereTobias Ribizel1-0/+70
Currently, LLVM's LineEditor and LLDB both use libedit, but find them in different (inconsistent) ways. This causes issues e.g. when you are using a locally installed version of libedit, which will not be used by clang-query, but by lldb if picked up by FindLibEdit.cmake Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D124673
2022-04-22[doc] [cmake] Fix a typo in examples for the cmake directory docs. NFC.Martin Storsjö1-2/+2
The previous case was a tautology - this is probably what was intended. Differential Revision: https://reviews.llvm.org/D124072
2022-03-22[cmake] Demote fatal error to a warning when we don't know the Apple SDK in useLouis Dionne1-1/+1
Sometimes, we could be building for a platform where we don't link compiler-rt, so being able to figure out the right compiler-rt suffix isn't necessary, but we shouldn't fail the build.
2022-03-21[cmake] Handle iOS, watchOS and tvOS when finding compiler-rt on AppleLouis Dionne1-2/+20
This patch uses CMAKE_OSX_SYSROOT, which should contain the SDK path that we're building against on Apple platforms, to determine which platform we are compiling for and set the compiler-rt suffix accordingly. Differential Revision: https://reviews.llvm.org/D122161
2022-03-14Correctly find builtins library with clang-clTobias Hieta1-3/+7
When using COMPILER_RT_USE_BUILTINS_LIBRARY=ON and clang-cl there where several places where it didn't work as expected. First -print-libgcc-file-name has to be prefixed with /clang: Then the regex that matched the builtins library was wrong because the builtins library is called clang_rt.builtins_<arch>.lib and the regex only matched libclang_rt.builtins_arch.a With this commit you can use a runtime build on Windows with this option enabled. Reviewed By: phosek Differential Revision: https://reviews.llvm.org/D120698
2022-03-02[NFC] Fix typo in CMake commentLouis Dionne1-1/+1
2022-01-29[cmake] Partially deduplicate `{llvm,compiler_rt}_check_linker_flag` for ↵John Ericson2-17/+35
runtime libs and llvm We previously had a few varied definitions of this floating around. I had tried to make the one installed with LLVM handle all the cases, and then made the others use it, but this ran into issues with `HandleOutOfTreeLLVM` not working for compiler-rt, and also `CMAKE_EXE_LINKER_FLAGS` not working right without `CMP0056` set to the new behavior. My compromise solution is this: - No not completely deduplicate: the runtime libs will instead use a version that still exists as part of the internal and not installed common shared CMake utilities. This avoids `HandleOutOfTreeLLVM` or a workaround for compiler-rt. - Continue to use `CMAKE_REQUIRED_FLAGS`, which effects compilation and linking. Maybe this is unnecessary, but it's safer to leave that as a future change. Also means we can avoid `CMP0056` for now, to try out later, which is good incrementality too. - Call it `llvm_check_compiler_linker_flag` since it, in fact is about both per its implementation (before and after this patch), so there is no name collision. In the future, we might still enable CMP0056 and make compiler-rt work with HandleOutOfTreeLLVM, which case we delete `llvm_check_compiler_flag` and go back to the old way (as these are, in fact, linking related flags), but that I leave for someone else as future work. The original issue was reported to me in https://reviews.llvm.org/D116521#3248117 as D116521 made clang and LLVM use the common cmake utils. Reviewed By: sebastian-ne, phosek, #libunwind, #libc, #libc_abi, ldionne Differential Revision: https://reviews.llvm.org/D117537
2022-01-21Revert "[cmake] Duplicate `{llvm,compiler_rt}_check_linker_flag` for runtime ↵Petr Hosek1-0/+17
libs and llvm" This reverts commit 4af11272f57a4a6fed2932e9e0857b2c1a707c51.
2022-01-20[cmake] Duplicate `{llvm,compiler_rt}_check_linker_flag` for runtime libs ↵John Ericson1-17/+0
and llvm We previously had a few varied definitions of this floating around. I made the one installed with LLVM handle all the cases, and then made the others use it. This issue was reported to me in https://reviews.llvm.org/D116521#3248117 as D116521 made clang and llvm use the common cmake utils. Reviewed By: sebastian-ne, phosek, #libunwind, #libc, #libc_abi, ldionne Differential Revision: https://reviews.llvm.org/D117537
2022-01-19[cmake] Move HandleOutOfTreeLLVM to common cmake utilsJohn Ericson1-0/+80
This is better than libunwind and libcxxabi fishing it out of libcxx's module directory. It is done in prepartion for a better version of D117537 which deduplicates CMake logic instead of just renaming to avoid a name clash. Reviewed By: phosek, #libunwind, #libc_abi, Ericson2314 Differential Revision: https://reviews.llvm.org/D117617
2022-01-10[doc][cmake] Convert read-me for the common CMake utils to reSTJohn Ericson2-53/+59
@phosek mentioned others might want it reST for consistency. As I personally do not like Markdown at all and just did the "usual GitHub read-me thing" out of habit, I am more than happy to oblige. Also fix the typos found in the original. Reviewed By: phosek, lebedev.ri Differential Revision: https://reviews.llvm.org/D116524
2022-01-07[CMake] Factor out config prefix finding logicJohn Ericson1-0/+41
See the docs in the new function for details. I think I found every instance of this copy pasted code. Polly could also use it, but currently does something different, so I will save the behavior change for a future revision. We get the shared, non-installed CMake modules following the pattern established in D116472. It might be good to have LLD and Flang also use this, but that would be a functional change and so I leave it as future work. Reviewed By: beanz, lebedev.ri Differential Revision: https://reviews.llvm.org/D116521
2022-01-07[cmake] Add read-me for the common CMake utilsJohn Ericson1-0/+53
Now that I am adding more things there, I thought it prudent to document what should and should not go there, and how it is used. Reviewed By: lebedev.ri Differential Revision: https://reviews.llvm.org/D116524
2022-01-05[CMake] Move the AIX archiver settings to a modulePetr Hosek1-0/+9
This allows their reuse across projects. The name of the module is intentionally generic because we would like to move more platform checks there. Differential Revision: https://reviews.llvm.org/D115276
2021-12-30[cmake] Tweak warning in `extend_path` helper functionJohn Ericson1-1/+1
There was one more reference the word "install" I forgot to remove. Follow-up to bde561c4813952847112600e5efe72d9015556f7 / https://reviews.llvm.org/D115746
2021-12-30[compiler-rt][cmake] Factor out extend_install_path functionJohn Ericson1-0/+19
It is likely to become used again, if other projects want their own per-project install directory variables. `install` is removed from the name since it is not inherently about installing. Reviewed By: stephenneuendorffer Differential Revision: https://reviews.llvm.org/D115746
2021-11-05[libunwind] Try to add --unwindlib=none while configuring and building libunwindMartin Storsjö2-0/+28
If Clang is set up to link directly against libunwind (via the --unwindlib option, or the corresponding builtin default option), configuring libunwind will fail while bootstrapping (before the initial libunwind is built), because every cmake test will fail due to -lunwind not being found, and linking the shared library will fail similarly. Check if --unwindlib=none is supported, and add it in that case. Using check_c_compiler_flag on its own doesn't work, because that only adds the tested flag to the compilation command, and if -lunwind is missing, the linking step would still fail - instead try adding it to CMAKE_REQUIRED_FLAGS and restore the variable if it doesn't work. This avoids having to pass --unwindlib=none while building libunwind. Differential Revision: https://reviews.llvm.org/D112126
2021-10-27[CMake] Cache the compiler-rt library search resultsPetr Hosek1-0/+101
There's a lot of duplicated calls to find various compiler-rt libraries from build of runtime libraries like libunwind, libc++, libc++abi and compiler-rt. The compiler-rt helper module already implemented caching for results avoid repeated Clang invocations. This change moves the compiler-rt implementation into a shared location and reuses it from other runtimes to reduce duplication and speed up the build. Differential Revision: https://reviews.llvm.org/D88458
2021-10-21Revert "[CMake] Cache the compiler-rt library search results"Petr Hosek1-101/+0
This reverts commit 0eed292fbae22a8856682b07e1cb968424b49941, there are compiler-rt build failures that appear to have been introduced by this change.
2021-10-18[CMake] Cache the compiler-rt library search resultsPetr Hosek1-0/+101
There's a lot of duplicated calls to find various compiler-rt libraries from build of runtime libraries like libunwind, libc++, libc++abi and compiler-rt. The compiler-rt helper module already implemented caching for results avoid repeated Clang invocations. This change moves the compiler-rt implementation into a shared location and reuses it from other runtimes to reduce duplication and speed up the build. Differential Revision: https://reviews.llvm.org/D88458
generated by cgit v1.1 at 2024-07-16 20:27:00 +0000