aboutsummaryrefslogtreecommitdiff
path: root/cmake
AgeCommit message (Collapse)AuthorFilesLines
2022-11-10[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 (cherry picked from commit 3676a86a4322e8c2b9c541f057b5d3704146b8f3)
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-08-01 01:28:54 +0000