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`.
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
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
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
