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
1. Slightly document the "mark advanced" variable used to control the
installed CMake package dir.
I would document it more, but I am considering in the future adding
pkg-config support in this manner, after which `_PACKGE_DIR` is
probably better called `_CMAKE_PACKGE_DIR` or similar.
2. Convey the custom path to the legacy `llvm-config` binary.
Reviewed By: sebastian-ne
Differential Revision: https://reviews.llvm.org/D130539
This is the patch for LLVM proper in my series for adding GNUInstallDirs support in all project.
Additionally:
Create a new `CACHE STRING` variable, `LLVM_EXAMPLES_INSTALL_DIR`, to control where the examples are installed on analogy with the other variables.
---
This patch supersedes D28234, which tried to do the same thing but hand-rolled without GNUInstallDirs.
This patch nearly reverts commit 3 0fc88bf1dc15a72e2d9809d28019d386b7a7cc0, which was a revert of a prior attempt."
(I had to add a space here or else Phabricator detects a reference cycle and won't let me do the form submit.)
Reviewed By: compnerd
Differential Revision: https://reviews.llvm.org/D100810
This reverts commit 492de35df4.
I tried to apply John's changes in 8d897ec915 that were expected to
fix his patch but that didn't work unfortunately.
Reverting this again to fix the macOS bots and leave him more time to
investigate the issue.
This reverts commit 797b50d4be.
See the original D99484. @mib who noticed the original problem could not longer
reproduce it, after I tried and also failed. We are threfore hoping it went
away on its own!
Reviewed By: mib
Differential Revision: https://reviews.llvm.org/D115544
This is a new draft of D28234. I previously did the unorthodox thing of
pushing to it when I wasn't the original author, but since this version
- Uses `GNUInstallDirs`, rather than mimics it, as the original author
was hesitant to do but others requested.
- Is much broader, effecting many more projects than LLVM itself.
I figured it was time to make a new revision.
I am using this patch (and many back-ports) as the basis of
https://github.com/NixOS/nixpkgs/pull/111487 for my distro (NixOS). It
looked like people were generally on board in D28234, but I make note of
this here in case extra motivation is useful.
---
As pointed out in the original issue, a central tension is that LLVM
already has some partial support for these sorts of things. For example
`LLVM_LIBDIR_SUFFIX`, or `COMPILER_RT_INSTALL_PATH`. Because it's not
quite clear yet what to do about those, we are holding off on changing
libdirs and `compiler-rt`. for this initial PR.
---
On the advice of @lebedev.ri, I am splitting this up a bit per
subproject, starting with LLVM. To allow it to be more easily reviewed. This and the subsequent patch must be landed together, as this will not build alone. But the rest can be landed on their own.
Reviewed By: compnerd
Differential Revision: https://reviews.llvm.org/D100810
There were two main problems:
* The 'nativecodegen' pseudo-component was unconditionally adding
${native_tgt}CodeGen even though it conditionally added ${native_tgt}Info and
${native_tgt}Desc. This has been fixed by making ${native_tgt}CodeGen
conditional too
* The 'all' pseudo-component was causing library names like LLVMLLVMDemangle as
the expansion was to a library name and not a component. There doesn't seem to
be a list of available components anywhere so this has been fixed by moving the
expansion of 'all' back where it was before. This manifested in different ways
on different builders but it was the same root cause
llvm-svn: 366622
Some targets are missing LLVMDemangle, one is adding the LLVM prefix twice, and two
are hitting the very error this patch fixes for my target. Reverting while I work
through the reports.
llvm-svn: 366615
Summary:
If you use pseudo-targets like AllTargetsCodeGens in LLVM_DYLIB_COMPONENTS
then a test will fail because `./bin/llvm-config --shared-mode` can't
handle these targets. We can fix this by expanding them before embedding
the string into llvm-config
Reviewers: bogner
Reviewed By: bogner
Subscribers: mgorny, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D65011
llvm-svn: 366610
to reflect the new license.
We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.
llvm-svn: 351636
Summary:
`LLVM_TOOLS_INSTALL_DIR` was introduced in r272200 in order to override the directory
name into which to install LLVM's executable. However, `llvm-config --bindir` still reported
`$PREFIX/bin` independent of what LLVM_TOOLS_INSTALL_DIR was set to.
This fixes the out-of-tree clang standalone build for me.
Reviewers: beanz, tstellar
Reviewed By: tstellar
Subscribers: chapuni, tstellar, llvm-commits
Differential Revision: https://reviews.llvm.org/D22499
llvm-svn: 304458
Following the similar change to lit configuration, ensure that all CMake
booleans are canonicalized to 0/1 when being passed to llvm-config. This
fixes the incorrect interpretation of values when user passes another
value than the ON/OFF, and simplifies the code by removing unnecessary
string matching.
Furthermore, the code for --has-rtti and --has-global-isel has been
modified to print consistent values indepdently of the boolean used by
passed by the user to CMake. Sadly, the code already implicitly used
different values for the two (YES/NO for --has-rtti, ON/OFF for
--has-global-isel).
Include tests for all booleans and multi-value options in llvm-config.
Differential Revision: https://reviews.llvm.org/D28366
llvm-svn: 291593
Summary:
This is a re-commit of r257003, which was reverted,
along with the fixes from http://reviews.llvm.org/D15986.
r252532 added support for reporting the monolithic library
when LLVM_BUILD_LLVM_DYLIB is used. This would only be done
if the individual components were not found, and the dynamic
library is found.
This diff extends this as follows:
- If LLVM_LINK_LLVM_DYLIB is set, then prefer the shared
library, even if all component libraries exist.
- Two flags, --link-shared and --link-static are introduced
to provide explicit guidance. If --link-shared is passed
and the shared library does not exist, an error results.
Additionally, changed the expected shared library names from
(e.g.) LLVM-3.8.0 to LLVM-3.8. The former exists only in an
installation (and then only in CMake builds I think?), and not
in the build tree; this breaks usage of llvm-config during
builds, e.g. by llvm-go.
Reviewers: DiamondLovesYou, beanz
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D15986
llvm-svn: 258283
Summary:
r252532 added support for reporting the monolithic library
when LLVM_BUILD_LLVM_DYLIB is used. This would only be done
if the individual components were not found, and the dynamic
library is found.
This diff extends this as follows:
- If LLVM_LINK_LLVM_DYLIB is set, then prefer the shared
library, even if all component libraries exist.
- Two flags, --link-shared and --link-static are introduced
to provide explicit guidance. If --link-shared is passed
and the shared library does not exist, an error results.
Additionally, changed the expected shared library names from
(e.g.) LLVM-3.8.0 to LLVM-3.8. The former exists only in an
installation (and then only in CMake builds I think?), and not
in the build tree; this breaks usage of llvm-config during
builds, e.g. by llvm-go.
Reviewers: DiamondLovesYou, beanz
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D15033
llvm-svn: 257003
Summary:
This patch does a couple of things:
- Adds a new argument `--shared-mode` which accepts a list of components and prints whether or not the provided components need to be linked statically or shared.
- Fixes `--libnames` when CMake BUILD_SHARED_LIBS is used.
- Fixes `--libnames`, `--libs`, and `--libfiles` for dylib when static components aren't installed.
- Fixes `--libnames`, `--libs`, `--libfiles`, and `--components` to use LLVM_DYLIB_COMPONENTS as the component manifest for dylib linking.
- Uses the host platform's usual convention for filename extensions and such, instead of always defaulting to Unix-izms.
Because I don't own a Mac, I am not able to test the Mac platform dependent stuff locally. If someone would be willing to run a build for me on their machine (unless there's a better option), I'd appreciate it.
Reviewers: jfb, brad.king, whitequark, beanz
Subscribers: beanz, jauhien, llvm-commits
Differential Revision: http://reviews.llvm.org/D13198
llvm-svn: 252532
Summary:
This prints NO if LLVM was built with -fno-rtti or an equivalent flag
and YES otherwise. The reasons to add -has-rtti rather than adding -fno-rtti
to --cxxflags are:
1. Building LLVM with -fno-rtti does not always mean that client
applications need this flag.
2. Some compilers have a different flag for disabling rtti, and the
compiler being used to build LLVM may not be the compiler being used to
build the application.
Reviewers: echristo, chandlerc, beanz
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D11849
llvm-svn: 252075
Summary:
This can be used for distinguishing between cmake and autoconf builds.
Users may need this in order to handle inconsistencies between the
outputs of the two build systems.
Reviewers: echristo, chandlerc, beanz
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D11838
llvm-svn: 247159
It seems I was wrong thinking `autoconf`/`make` only installed shared libraries if configured with `--enable-shared`, even if `--disable-static` is present. I'll re-address with a followup patch.
This reverts commit r243297 for causing PR#24154.
llvm-svn: 244108
Summary:
When LLVM is configured to build shared libraries, CMake builds each component as it's own shared object, while autoconfig/make builds them statically and then links them all together to create a single shared object. This change adds compile time config flags to `llvm-config` so it can know whether LLVM's components are separated or not and act accordingly.
This fixes `llvm-config` instead of fixing the makefiles to behave like CMake because, AIUI, LLVM's autoconfig/make build system is on the way out anyway.
This change only affects `llvm-config` from builds that use autoconfig/make.
Reviewers: jfb
Subscribers: echristo, dschuff, llvm-commits
Differential Revision: http://reviews.llvm.org/D11392
llvm-svn: 243297
This reverts commit 01446706b4c0a86bb64768f307079cab5c514aa3.
Causes breakage, seems to be related to 'svn' in the file's name:
CC=gcc CXX=g++ \
../llvm/configure \
--prefix=/usr \
--sysconfdir=/etc \
--enable-shared \
--enable-libffi \
--enable-targets=all \
--disable-assertions \
--with-python=/usr/bin/python2 \
--enable-optimized
make REQUIRES_RTTI=1 ENABLE_PIC=1
results:
llvm[2]: Linking Release unit test Support (without symbols)
llvm[2]: ======= Finished Linking Release Unit test Support (without symbols)
make[3]: Entering directory '/build/llvm-svn/src/build/bindings/ocaml/llvm'
make[3]: *** No rule to make target '/build/llvm-
svn/src/build/Release/lib/ocaml/libLLVM-3.7.0svn.so', needed by 'build-
deplibs'. Stop.
make[3]: *** Waiting for unfinished jobs....
llvm[3]: Compiling llvm_ocaml.c for Release build
make[3]: Leaving directory '/build/llvm-svn/src/build/bindings/ocaml/llvm'
/build/llvm-svn/src/llvm/Makefile.rules:880: recipe for target 'all' failed
/build/llvm-svn/src/llvm/Makefile.rules:965: recipe for target 'all' failed
Differential Revision: http://reviews.llvm.org/D10716
llvm-svn: 242152
Summary:
This fixes `llvm-config` instead of fixing the makefiles because, AIUI, LLVM's autoconfig/make build system is on the way out anyway.
This change only affects builds that use autoconfig/make.
Reviewers: jfb
Subscribers: echristo, dschuff, llvm-commits
Differential Revision: http://reviews.llvm.org/D10716
llvm-svn: 241938
For this to work, we have to encode it in the build variables and use it
from llvm-config.cpp. I've tried to do this reasonably cleanly, but the
code for llvm-config.cpp is pretty strange. However, with this,
llvm-config stops giving the wrong answer when using LLVM_LIBDIR_SUFFIX.
Note that the configure+make build just sets this to an empty string as
that build system has zero support for multilib of any form. I'm not
planning to add support there either, but this should leave a path for
anyone that wanted to.
llvm-svn: 224921
properly initializing the target infos. I decided it wasn't worth linking them
in for this, so just switched back to using the Makefile variable for now. We
can reconsider later if we ever get pluggable targets.
llvm-svn: 146711
Original commit message:
llvm-config: Replace with C++ version (was llvm-config-2).
- Reapply of r144300, with lots of fixes/migration easement in between.
llvm-svn: 145582
John Ericson