summaryrefslogtreecommitdiff
path: root/lld/cmake
Commit message (Collapse)AuthorAgeFilesLines
* [cmake] Fix path to LLVMConfig.cmake for multi-config buildsNhat Nguyen2023-01-131-1/+2
| | | | | | | | | | | | D139623 replaces CMAKE_CFG_INTDIR with '.' for multi-config builds. However, this change has not been reflected in mlir, flang, polly, lld, and clang. The patch updates the path to LLVMConfig.cmake for those projects. Reviewed By: sebastian-ne Differential Revision: https://reviews.llvm.org/D141538
* Add version to all LLVM cmake packageThomas Preud'homme2022-11-253-1/+24
| | | | | | | | | | Add a version to non-LLVM cmake package so that users needing an exact version match can use the version parameter to find_package. Also adjust the find_package(LLVM) to use an exact version match as well. Reviewed By: arsenm, stellaraccident, mceier Differential Revision: https://reviews.llvm.org/D138274
* Revert: Add version to all LLVM cmake packageThomas Preud'homme2022-11-253-24/+1
| | | | | | | | Summary: This reverts commit ad485b71b51168ce13282ae159bd8feff48baf84. Reviewers: Subscribers:
* Add version to all LLVM cmake packageThomas Preud'homme2022-11-203-1/+24
| | | | | | | | | | Add a version to non-LLVM cmake package so that users needing an exact version match can use the version parameter to find_package. Also adjust the find_package(LLVM) to use an exact version match as well. Reviewed By: arsenm, stellaraccident Differential Revision: https://reviews.llvm.org/D138274
* [CMake] Avoid `LLVM_BINARY_DIR` when other more specific variable are ↵John Ericson2022-09-141-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | better-suited, part 2 A simple sed doing these substitutions: - `${LLVM_BINARY_DIR}/lib${LLVM_LIBDIR_SUFFIX}\>` -> `${LLVM_LIBRARY_DIR}` - `${LLVM_BINARY_DIR}/bin\>` -> `${LLVM_TOOLS_BINARY_DIR}` where `\>` means "word boundary". The only manual modifications were reverting changes in - `runtimes/CMakeLists.txt` because these were "entry points" where we wanted to tread carefully not not introduce a "loop" which would end with an undefined variable being expanded to nothing. There are some `${LLVM_BINARY_DIR}/lib` without the `${LLVM_LIBDIR_SUFFIX}`, but these refer to the lib subdirectory of the source (`llvm/lib`). That `lib` is automatically appended to make the local `CMAKE_CURRENT_BINARY_DIR` value by `add_subdirectory`; since the directory name in the source tree is fixed without any suffix, the corresponding `CMAKE_CURRENT_BINARY_DIR` will also be. We therefore do not replace it but leave it as-is. This picks up where D133828 left off, getting the occurrences with*out* `CMAKE_CFG_INTDIR`. But this is difficult to do correctly and so not done in the (retroactively) previous diff. This hopefully increases readability overall, and also decreases the usages of `LLVM_LIBDIR_SUFFIX`, preparing us for D130586. Reviewed By: sebastian-ne Differential Revision: https://reviews.llvm.org/D132316
* Revert "[CMake] Avoid `LLVM_BINARY_DIR` when other more specific variable ↵John Ericson2022-08-251-1/+1
| | | | | | are better-suited" This reverts commit ad8c34bc3089d847a09bb740f7a58c96073e0959.
* [CMake] Avoid `LLVM_BINARY_DIR` when other more specific variable are ↵John Ericson2022-08-241-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | better-suited A simple sed doing these substitutions: - `${LLVM_BINARY_DIR}/(\$\{CMAKE_CFG_INTDIR}/)?lib(${LLVM_LIBDIR_SUFFIX})?\>` -> `${LLVM_LIBRARY_DIR}` - `${LLVM_BINARY_DIR}/(\$\{CMAKE_CFG_INTDIR}/)?bin\>` -> `${LLVM_TOOLS_BINARY_DIR}` where `\>` means "word boundary". The only manual modifications were reverting changes in - `compiler-rt/cmake/Modules/CompilerRTUtils.cmake - `runtimes/CMakeLists.txt` because these were "entry points" where we wanted to tread carefully not not introduce a "loop" which would end with an undefined variable being expanded to nothing. This hopefully increases readability overall, and also decreases the usages of `LLVM_LIBDIR_SUFFIX`, preparing us for D130586. Reviewed By: sebastian-ne Differential Revision: https://reviews.llvm.org/D132316
* Revert "[cmake] Use `CMAKE_INSTALL_LIBDIR` too"John Ericson2022-08-182-4/+4
| | | | | | | This reverts commit f7a33090a91015836497c75f173775392ab0304d. Unfortunately this causes a number of failures that didn't show up in my local build.
* [cmake] Use `CMAKE_INSTALL_LIBDIR` tooJohn Ericson2022-08-182-4/+4
| | | | | | | | | | | | | | | | | | 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
* [CMake] Fix add_subdirectory llvm buildsSebastian Neubauer2022-07-261-1/+1
| | | | | | | Fixes a regression from D117973, that used CMAKE_BINARY_DIR instead of LLVM_BINARY_DIR in some places. Differential Revision: https://reviews.llvm.org/D130555
* [cmake] Support custom package install pathsJohn Ericson2022-07-251-6/+11
| | | | | | | | | | | | | | | | | | | | | 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
* [cmake] Don't export `LLVM_TOOLS_INSTALL_DIR` anymoreJohn Ericson2022-07-211-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Revert "[cmake] Don't export `LLVM_TOOLS_INSTALL_DIR` anymore"John Ericson2022-06-101-2/+2
| | | | This reverts commit d5daa5c5b091cafb9b7ffd19b5dfa2daadef3229.
* [cmake] Don't export `LLVM_TOOLS_INSTALL_DIR` anymoreJohn Ericson2022-06-101-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [CMake] Factor out config prefix finding logicJohn Ericson2022-01-071-10/+2
| | | | | | | | | | | | | | | | | | 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
* [lld][CMake] Use `GNUInstallDirs` to support custom installation dirsJohn Ericson2021-12-312-3/+6
| | | | | | | | | 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
* [cmake] Add support for multiple distributionsShoaib Meenai2021-05-123-22/+8
| | | | | | | | | | | | LLVM's build system contains support for configuring a distribution, but it can often be useful to be able to configure multiple distributions (e.g. if you want separate distributions for the tools and the libraries). Add this support to the build system, along with documentation and usage examples. Reviewed By: phosek Differential Revision: https://reviews.llvm.org/D89177
* lld: Let find_package(LLD) workMatt Arsenault2020-05-143-2/+86
| | | | | | | | 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.
* [CMake] Properly conditionalize installation of lld librariesDavid Zarzycki2018-03-091-1/+1
| | | | | | | | | | | | | | In what appears to be a copy-and-paste error, lld currently only installs libraries if the lld tools are configured to build. Instead, lld should allow the libraries to be installed even if the lld tools are not being built. Additionally, if users want to only install the tools and not the libraries, the LLVM way of doing that is by checking for LLVM_INSTALL_TOOLCHAIN_ONLY. This fixes PR35960. llvm-svn: 327126
* [lld] Switch to add_llvm_install_targetsShoaib Meenai2017-12-011-8/+4
| | | | | | | | This adds install-*-stripped targets that strip during installation. Differential Revision: https://reviews.llvm.org/D40688 llvm-svn: 319517
* [lld][cmake] Fix BUILD_SHARED_LIBS installationPavel Labath2017-01-241-1/+33
| | | | | | | | | | | | | | | | | | | Summary: This fixes a regression caused by D28397, which switched lld from using add_llvm_library to llvm_add_library. The latter does not automatically set up install rules for libraries, as it's expected the project will set them up manually based on its own needs. This adds the install rules to add_lld_library for lld. They were inspired by the similar add_clang_library macro in clang. Reviewers: ruiu, beanz, davidlt, EricWF, dtzWill Subscribers: mgorny, llvm-commits Differential Revision: https://reviews.llvm.org/D29007 llvm-svn: 292909
* [lld][cmake] Fix LLVM_LINK_LLVM_DYLIB buildPavel Labath2017-01-091-1/+1
| | | | | | | | | | | | | | | | | | | | | | | Summary: Lld's build had a couple of issues which prevented a successfull LLVM_LINK_LLVM_DYLIB compilation. - add_llvm_library vs llvm_add_library: One adds a library to libLLVM.so, other one doesn't. Lld was using the wrong one, causing symbols to be mupltiply defined in things linking to libLLVM. - confusion when to use LINK_LIBS vs LINK_COMPONENTS in llvm_add_library - not using LLVM_LINK_COMPONENTS for add_lld_tool With these fixes lld compiles and it's test suite passes both in LLVM_LINK_LLVM_DYLIB mode and without it. Reviewers: ruiu, beanz Subscribers: llvm-commits, mgorny Differential Revision: https://reviews.llvm.org/D28397 llvm-svn: 291432
* [CMake] Add install target for the lld toolPetr Hosek2016-12-231-0/+45
| | | | | | | | | | 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
* Add VTune as an optional external dependency and add task tracking.Michael J. Spencer2013-04-061-0/+31
llvm-svn: 178940
View Lorry Controller Status