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.
Fix the builds with LLVM_TOOL_LLVM_DRIVER_BUILD enabled.
LLVM_ENABLE_EXPORTED_SYMBOLS_IN_EXECUTABLES is not completely
compatible with export_executable_symbols as the later will be ignored
if the previous is set to NO.
Fix the issue by passing if symbols need to be exported to
llvm_add_exectuable so the link flag can be determined directly
without calling export_executable_symbols_* later.
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.
Previously, even though LLD was linked as part of llvm-driver when using
`cmake ... -DLLVM_TOOL_LLVM_DRIVER_BUILD=ON`, there were build issues
when compiling incrementally. Sometimes link errors when linking LLD,
other times, the `llvm.exe` would be impropely be replaced by `lld.exe`.
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 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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
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
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
