The mechanism behind "check-all" is recording params of add_lit_testsuite()
calls in global variables LLVM_LIT_*, and then creating an extra suite with
their union at the end.
This avoids composing the check-* targets directly, which doesn't work well.
We generalize this by allowing multiple families of variables LLVM_{name}_LIT_*:
umbrella_lit_testsuite_begin(check-foo)
... test suites here will be added to LLVM_FOO_LIT_* variables ...
umbrella_lit_testsuite_end(check-foo)
(This also moves some implementation muck out of {llvm,clang}/CMakeLists.txt
This patch also changes check-clang-tools to use be an umbrella test target,
which means the clangd and clang-pseudo tests are included in it, along with the
the other testsuites that already are (like check-clang-extra-clang-tidy).
Differential Revision: https://reviews.llvm.org/D121838
CLANG_TOOLS_DIR holds the the current bin/ directory, maybe with a %(build_mode)
placeholder. It is used to add the just-built binaries to $PATH for lit tests.
In most cases it equals LLVM_TOOLS_DIR, which is used for the same purpose.
But for a standalone build of clang, CLANG_TOOLS_DIR points at the build tree
and LLVM_TOOLS_DIR points at the provided LLVM binaries.
Currently CLANG_TOOLS_DIR is set in clang/test/, clang-tools-extra/test/, and
other things always built with clang. This is a few cryptic lines of CMake in
each place. Meanwhile LLVM_TOOLS_DIR is provided by configure_site_lit_cfg().
This patch moves CLANG_TOOLS_DIR to configure_site_lit_cfg() and renames it:
- there's nothing clang-specific about the value
- it will also replace LLD_TOOLS_DIR, LLDB_TOOLS_DIR etc (not in this patch)
It also defines CURRENT_LIBS_DIR. While I removed the last usage of
CLANG_LIBS_DIR in e4cab4e24d1, there are LLD_LIBS_DIR usages etc that
may be live, and I'd like to mechanically update them in a followup patch.
Differential Revision: https://reviews.llvm.org/D121763
This clarifies that this is an LLVM specific variable and avoids
potential conflicts with other projects.
Differential Revision: https://reviews.llvm.org/D119918
The upstream project ships CMake rules for building vanilla gtest/gmock which conflict with the names chosen by LLVM. Since LLVM's build rules here are quite specific to LLVM, prefixing them to avoid collision is the right thing (i.e. there does not appear to be a path to letting someone *replace* LLVM's googletest with one they bring, so co-existence should be the goal).
This allows LLVM to be included with testing enabled within projects that themselves have a dependency on an official gtest release.
Reviewed By: mehdi_amini
Differential Revision: https://reviews.llvm.org/D120789
since it qualifies as a toolchain tool rather than "internal llvm tool".
This will make it part of builds which set the
LLVM_INSTALL_TOOLCHAIN_ONLY cmake option, such as the Windows installer.
Differential revision: https://reviews.llvm.org/D118042
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
As Visual Studio's CMake support is getting better and better the line
between IDE generator and non-IDE generators is blurring. Visual Studio
2019 and later have a very useful UI that can handle all of the various
targets we create, but if they are unsorted it is wildly unwieldy.
This change sorts the lit testsuite targets and per-component install
targets into folders, which are not generated for IDE generators but
are generated by default under Visual Studio's CMake + Ninja
integration.
This reverts 8cb7876cb366b5803ca35d92313ea00eadf29b78 and follow-ups.
GNU ld/gold/ld.lld -O has nothing to do with any code related linker optimizations.
It has very small benefit (save 144Ki (.hash, .gnu_hash) with GNU ld, save 0.7%
.debug_str with gold/ld.lld) while it makes gold/ld.lld significantly slower
when linking RelWithDebInfo clang (gold: 16.437 vs 19.488; ld.lld: 1.882 vs 4.881).
This reverts commit 492de35df443d5f31480173d5f1274c7835cd3d8.
I tried to apply John's changes in 8d897ec91528 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 797b50d4be873b4662983413a06806fca544c276.
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
When cross-compiling LLVM in an environment where there //is// an
objdump binary available but it does not understand the target
platform's object file format, extract_symbols.py fails, because its
initial check for tool availability decides that the existence of
objdump at all is good enough to settle on it as the tool of choice.
In such an environment it's useful to work around this by telling
extract_symbols.py to use llvm-readobj instead. The script itself has
an option for that, but its invocation in AddLLVM.cmake wasn't
providing a mechanism to add extra options passed through for the
cmake command line.
Reviewed By: DavidSpickett
Differential Revision: https://reviews.llvm.org/D113557
LLVM_LINKER_IS_LLD is now set with LLVM_ENABLE_LLD=ON (or LLVM_USER_LINKER=lld)
even on APPLE, and we pass -Wl,-order_file when LLVM_LINKER_IS_LLD on APPLE
too.
To make this straightforward, change the linker detection logic to go through
the compiler driver on APPLE like on the other platforms.
No intended behavior change if LLVM_ENABLE_LLD isn't set.
Differential Revision: https://reviews.llvm.org/D113021
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
- Both LLVM_REQUIRES_RTTI and LLVM_REQUIRES_EH are internal flags that
individual targets can use to force RTTI/EH. Turning off
LLVM_REQUIRES_RTTI should honor if that variable is set explicitly for
an individual target.
mold says it is compatible with GNU ld and gold linkers:
```
$ mold -v
mold 0.9.5 (compatible with GNU ld and GNU gold)
```
And thus it currently gets detected as Gold.
With the following diff, CMake now correctly reports the linker name, and mold keeps being identified as Gold internally for now.
Reviewed By: ldionne, MaskRay
Differential Revision: https://reviews.llvm.org/D110035
This reverts commit 6d7b3d6b3a8dbd62650b6c3dae1fe904a8ae9048.
Breaks running cmake with `-DCLANG_ENABLE_STATIC_ANALYZER=OFF`
without turning off CLANG_TIDY_ENABLE_STATIC_ANALYZER.
See comments on https://reviews.llvm.org/D109611 for details.
Since https://reviews.llvm.org/D87118, the StaticAnalyzer directory is
added unconditionally. In theory this should not cause the static analyzer
sources to be built unless they are referenced by another target. However,
the clang-cpp target (defined in clang/tools/clang-shlib) uses the
CLANG_STATIC_LIBS global property to determine which libraries need to
be included. To solve this issue, this patch avoids adding libraries to
that property if EXCLUDE_FROM_ALL is set.
In case something like this comes up again: `cmake --graphviz=targets.dot`
is quite useful to see why a target is included as part of `ninja all`.
Reviewed By: thakis
Differential Revision: https://reviews.llvm.org/D109611
The original change to add the workaround is from 10 years ago and a lot has happened with msvc and cmake and llvm's usage of cmake since and we no longer need the workaround for any scenarios that I am aware of. Build more is now correctly configured for multi-configuration generators such as Visual Studio.
The workaround is, however, causing issues with some of the recent mlir tests as because of the workaround we cannot correctly determine whether assertions are enabled (see https://reviews.llvm.org/D105961).
The original change is:
```
commit b46fdac4609df2613177813d43a124e3d9a8a306
Author: Andrew Trick <atrick@apple.com>
Date: Tue Jun 28 16:32:01 2011
cmake: Our MSVC build does not support config-time build mode.
llvm-svn: 134008
```
Reviewed By: mehdi_amini
Differential Revision: https://reviews.llvm.org/D109521
so that it gets installed in LLVM_INSTALL_TOOLCHAIN_ONLY builds,
such as used by the Windows installer.
Differential revision: https://reviews.llvm.org/D109358
It's sometimes useful to use these directives when dealing with
external projects:
target_link_directories
target_link_libraries
target_include_directories
However, under certain circumstances,
llvm_add_library can generate multiple targets. We need to transfer
these properties to the new targets. Note that using a generator
expression is necessary because these properties will only be set
after llvm_add_library is called.
Differential Revision: https://reviews.llvm.org/D108098
This is just a workaround. Pass the `-mllvm,-O0` link flags only if its
not ThinLTO. Doing that with ThinLTO currently results in an error:
```
Remaining virtual register operands
UNREACHABLE executed at .../llvm/lib/CodeGen/MachineRegisterInfo.cpp:209!
```
This patch adds llvm-readobj and the binutils symlink for readelf to
LLVM_TOOLCHAIN_TOOLS.
Tvoid *thread, void *attr,hey are required by some (most?)
autoconf-built libraries, adding these allows me to build newlib with
the toolchain generated this way.
Also opened an issue for that some days ago, see
https://bugs.llvm.org/show_bug.cgi?id=50698
Reviewed By: sbc100
Differential Revision: https://reviews.llvm.org/D104957
`llvm-strip` does not support `-l`. Apple's `strip` supports `-l`, but
it is not documented, and the latest code doesn't seem to do anything
meaningful. From the old source code drops it seems that `-l` was added
around version 795 of cctools and removed before 898. The code around
the flag usage in 795 talks about problems with kext and forcing the
execution of `ld -r`, which seems a behaviour that is not enforceable in
latest versions of cctools.
The `-l` flag was added in https://reviews.llvm.org/D15133 without a lot
of explanation.
Since the flag is not active, removing it should not modify the
behaviour for most people (except if someone is trying to compile LLVM
with a really old version of `strip`).
Additionally, break the invocation into two different flags, since
`llvm-strip` doesn't at the moment support grouped flags, and other
`strip` implementations should work the same no matter if grouped or
not.
Test Plan:
Using `strip` from Xcode 12.5 in Big Sur to strip the same binary (a
simple Hello World), using both `-Sxl` and `-Sx` produces exactly the
same binary.
Repeating the same process with `clang` results also in the same binary.
Reviewed By: smeenai
Differential Revision: https://reviews.llvm.org/D105243
This is an attempt to fix clang test failures due to 'nonportable-include-path'
warnings on Windows when a path to llvm-project's base directory contains some
uppercase letters (excluding a drive letter).
The issue originates from 2 problems:
* discovery.py loads site config in lower case causing all the paths
based on __file__ and requested within the config file to be in lowercase as well,
* neither os.path.abspath() nor os.path.realpath() (both used to obtain paths of
config files, sources, object directories, etc) do not return paths in the correct
case for Windows (at least consistently for all python versions).
As os.path library doesn't seem to provide any relaible way to restore
the case for paths on Windows, this patch proposes to use pathlib.resolve().
pathlib is a part of Python 3.4 while llvm lit requires Python 3.6.
Reviewed By: Meinersbur
Differential Revision: https://reviews.llvm.org/D103014
We already use -O0 for unittests under ThinLTO, do the same for full LTO
where the compile time costs to runtime benefits tradeoff is even worse.
Differential Revision: https://reviews.llvm.org/D102718
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
If compiling with GCC or linking with ld.bfd, these options have little
effect, but if built with Clang and linked with LLD, they provide a
quite notable size decrease - this shrinks an entire llvm-mingw
distribution package by 22%.
If building with BUILD_SHARED_LIBS or LLVM_BUILD_LLVM_DYLIB with LLD,
this requires a version of LLD that contains a fix for auto exporting
symbols from comdats, 2b01a417d7ccb001ccc1185ef5fdc967c9fac8d7.
Differential Revision: https://reviews.llvm.org/D101568
Match the API for the new check_linker_flag and use it directly when
available, leaving the old code as a fallback.
Differential Revision: https://reviews.llvm.org/D100901
This makes it possible to build libLLVM.so without first creating a
static library for each component. In the case where only libLLVM.so is
built (i.e. ninja LLVM) this eliminates 150 linker jobs.
Reviewed By: stellaraccident
Differential Revision: https://reviews.llvm.org/D95727
BUILD_SHARED_LIBS build llvm component as shared library,
which can reduce the size a lot.
Normally, the binary use ORIGIN../lib to load component libraries,
unfortunatly, ORIGIN is not supported by AIX ld.
We hardcoded the build lib and install lib path in rpath for now
to enable BUILD_SHARED_LIBS build.
Understand that this is not perfect solution,
we can update this when we find better solution.
Reviewed By: hubert.reinterpretcast
Differential Revision: https://reviews.llvm.org/D98901
This drops check-llvm under -DLLVM_ENABLE_LTO=Thin from 13m to 10m20s on Windows and 20m to 15m35s on Linux.
Reviewed By: hans
Differential Revision: https://reviews.llvm.org/D96618
Multi-configuration generators (such as Visual Studio and Xcode) allow the specification of a build flavor at build time instead of config time, so the lit configuration files need to support that - and they do for the most part. There are several places that had one of two issues (or both!):
1) Paths had %(build_mode)s set up, but then not configured, resulting in values that would not work correctly e.g. D:/llvm-build/%(build_mode)s/bin/dsymutil.exe
2) Paths did not have %(build_mode)s set up, but instead contained $(Configuration) (which is the value for Visual Studio at configuration time, for Xcode they would have had the equivalent) e.g. "D:/llvm-build/$(Configuration)/lib".
This seems to indicate that we still have a lot of fragility in the configurations, but also that a number of these paths are never used (at least on Windows) since the errors appear to have been there a while.
This patch fixes the configurations and it has been tested with Ninja and Visual Studio to generate the correct paths. We should consider removing some of these settings altogether.
Reviewed By: JDevlieghere, mehdi_amini
Differential Revision: https://reviews.llvm.org/D96427
d9ce31ae7d (D94322) removed the check because I thought it was dead
due to checking the existance of a variable (which always existed).
This causes LLDB tests to fail as they set NO_INSTALL_RPATH because
they're never meant to be installed, but we still would end up using
the install rpath.
Add the check back and make it explicitly check for an empty value
to make the purpose clearer and avoid implicit test for a false/true
value.
Differential Revision: https://reviews.llvm.org/D94326
Reverted check for empty CMAKE_BUILD_RPATH fixed.
When `BUILD_WITH_INSTALL_RPATH` is enabled it prevents using a custom rpath only
for the build tree as the install rpath will be used. This makes it impossible to run a
runtimes build when compiling with Clang and wanting the installed rpath to be
empty (i.e. `-DCMAKE_BUILD_RPATH="<some path>" -DCMAKE_SKIP_INSTALL_RPATH=ON`).
Disable `BUILD_WITH_INSTALL_RPATH` when `CMAKE_BUILD_RPATH` is non-empty to
allow for such build scenarios.
Differential Revision: https://reviews.llvm.org/D94322
This reverts commit 0ebc1fb29f278db0665423f15c53e6ee9601dddb.
The behaviour should have been the same as before unless specifying CMAKE_BUILD_RPATH,
which was previously broken.
However, this seems to have broken builds for some people that don't specify it.
Reverting until I can investigate.
Differential Revision: https://reviews.llvm.org/D94319
When `BUILD_WITH_INSTALL_RPATH` is enabled it prevents using a custom rpath only
for the build tree as the install rpath will be used. This makes it impossible to run a
runtimes build when compiling with Clang and wanting the installed rpath to be
empty (i.e. `-DCMAKE_BUILD_RPATH="<some path>" -DCMAKE_SKIP_INSTALL_RPATH=ON`).
Disable `BUILD_WITH_INSTALL_RPATH` when `CMAKE_BUILD_RPATH` is non-empty to
allow for such build scenarios.
Reviewed By: phosek
Differential Revision: https://reviews.llvm.org/D93177
Set the return variable to "" in find_first_existing_vc_file to
say that there is a repository, but no file to depend on. This works
transparently for all other callers that handle undefinedness and
equality to an empty string the same way.
Use the knowledge to avoid depending on __FakeVCSRevision.h if there
is no git repository at all (for example when building a release) as
there is no point in regenerating an empty VCSRevision.h.
Differential Revision: https://reviews.llvm.org/D92718
