The problem on Windows was that the \b in "..\bin" was interpreted
as an escape sequence. Use r"" strings to prevent that.
This reverts commit ab11b9eefa,
with raw strings in the lit.site.cfg.py.in files.
Differential Revision: https://reviews.llvm.org/D77184
Currently, all generated lit.site.cfg files contain absolute paths.
This makes it impossible to build on one machine, and then transfer the
build output to another machine for test execution. Being able to do
this is useful for several use cases:
1. When running tests on an ARM machine, it would be possible to build
on a fast x86 machine and then copy build artifacts over after building.
2. It allows running several test suites (clang, llvm, lld) on 3
different machines, reducing test time from sum(each test suite time) to
max(each test suite time).
This patch makes it possible to pass a list of variables that should be
relative in the generated lit.site.cfg.py file to
configure_lit_site_cfg(). The lit.site.cfg.py.in file needs to call
`path()` on these variables, so that the paths are converted to absolute
form at lit start time.
The testers would have to have an LLVM checkout at the same revision,
and the build dir would have to be at the same relative path as on the
builder.
This does not yet cover how to figure out which files to copy from the
builder machine to the tester machines. (One idea is to look at the
`--graphviz=test.dot` output and copy all inputs of the `check-llvm`
target.)
Differential Revision: https://reviews.llvm.org/D77184
Summary:
In D76527, we stopped exporting symbols from clang, opt and llc unless
the `LLVM_ENABLE_PLUGINS` cmake variable is true (which causes clang's
own plugin collection to be built).
But another reasonable build configuration is to ask clang to export
its symbols for out-of-tree plugins to use, without building the
in-tree ones. That is, you might set `LLVM_EXPORT_SYMBOLS_FOR_PLUGINS`
without also setting `LLVM_ENABLE_PLUGINS` (at least if you're using
MSVC, where you need to ask explicitly for the symbols to be
exported).
In that situation, the symbols should still be exported, but after
D76527, they weren't being.
Reviewers: efriedma, john.brawn
Reviewed By: efriedma, john.brawn
Subscribers: mgorny, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D76760
The only reason we export symbols from these tools is to support
plugins; if we don't have plugins, exporting symbols just bloats the
executable and makes LTO less effective.
See review of D75879 for the discussion that led to this patch.
Differential Revision: https://reviews.llvm.org/D76527
Using INTERFACE prevents the use of imported libraries as we've done
in 00b3d49 because these aren't linked against the target, they're
only made part of the interface. This doesn't affect the output since
static libraries aren't being linked into, but it enables the use of
imported libraries.
Differential Revision: https://reviews.llvm.org/D74106
Pass plugins introduced in D61446 do not support dynamic linking on
Windows, hence the option LLVM_${name_upper}_LINK_INTO_TOOLS can only
work being set to "ON". Currently, it defaults to "OFF" such that such
plugins are inoperable by default on Windows. Change the default for
subprojects to follow LLVM_ENABLE_PROJECTS.
Reviewed By: serge-sans-paille, MaskRay
Differential Revision: https://reviews.llvm.org/D72372
Use a dedicated cmake file to store the extension configured within LLVM. That
way, a standalone build of clang can load this cmake file and get all the
configured standalone extensions.
This patch is related to https://reviews.llvm.org/D74602
Differential Revision: https://reviews.llvm.org/D74757
Summary:
Otherwise, the build output contains a bunch of "Linker detection: <xxx>"
lines that are really redundant. We also make redundant calls to the
linker, although that is a smaller concern.
Reviewers: smeenai
Subscribers: mgorny, fedor.sergeev, jkorous, dexonsmith, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D68648
EXCLUDE_FROM_ALL means something else for add_lit_testsuite as it does
for something like add_executable. Distinguish between the two by
renaming the variable and making it an argument to add_lit_testsuite.
Differential revision: https://reviews.llvm.org/D74168
- Update documentation now that the move to monorepo has been made
- Do not tie compiler extension testing to LLVM_BUILD_EXAMPLES
- No need to specify LLVM libraries for plugins
- Add NO_MODULE option to match Polly specific requirements (i.e. building the
module *and* linking it statically)
- Issue a warning when building the compiler extension with
LLVM_BYE_LINK_INTO_TOOLS=ON, as it modifies the behavior of clang, which only
makes sense for testing purpose.
Still mark llvm/test/Feature/load_extension.ll as XFAIL because of a
ManagedStatic dependency that's going to be fixed in a seperate commit.
Differential Revision: https://reviews.llvm.org/D72327
https://reviews.llvm.org/D61446 introduced a new function to process
pass plugins that used CMAKE_BINARY_DIR. This is problematic when LLVM
is a subproject. Instead use LLVM_BINARY_DIR to get the right relative
directory for cmake.
Patch by Alan Baker <alanbaker@google.com>
Reviewed By: Meinersbur
Differential Revision: https://reviews.llvm.org/D72109
The install-${name}-stripped targets don't strip when ${name} is being
symlinked, e.g. llvm-ar or llvm-objcopy. The problem is that
llvm_install_symlink passes install-${dest} as a dependency of
install-${name}, e.g. install-llvm-ar becomes a dependency of both
install-llvm-ranlib and install-llvm-ranlib-stripped. What this means is
that when installing a distribution that contains both llvm-ar and
llvm-ranlib is that first the stripped version of llvm-ar is installed
(by the install-llvm-ar-stripped target) and then it's overwritten by an
unstripped version of llvm-ar bnecause install-llvm-ranlib-stripped has
install-llvm-ranlib as a dependency as mentioned earlier. To avoid this
issue, rather than passing the install-${dest} as dependency, we
introduce a new argument to add_llvm_install_targets for symlink target
which expands it into an appropriate dependency, i.e. install-${dest}
for install-${name} target and install-${dest}-stripped for
install-${name}-stripped.
Differential Revision: https://reviews.llvm.org/D71951
There's quite a lot of references to Polly in the LLVM CMake codebase. However
the registration pattern used by Polly could be useful to other external
projects: thanks to that mechanism it would be possible to develop LLVM
extension without touching the LLVM code base.
This patch has two effects:
1. Remove all code specific to Polly in the llvm/clang codebase, replaicing it
with a generic mechanism
2. Provide a generic mechanism to register compiler extensions.
A compiler extension is similar to a pass plugin, with the notable difference
that the compiler extension can be configured to be built dynamically (like
plugins) or statically (like regular passes).
As a result, people willing to add extra passes to clang/opt can do it using a
separate code repo, but still have their pass be linked in clang/opt as built-in
passes.
Differential Revision: https://reviews.llvm.org/D61446
Summary:
export_symbols.py discards duplicate symbols, assuming they have public definitions, so if we end
up calling it with duplicate libraries we will end up with an inaccurate export list.
Reviewers: jasonliu, stevewan, john.brawn
Reviewed By: john.brawn
Subscribers: mgorny, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D70918
Summary:
Most libraries are defined in the lib/ directory but there are also a
few libraries defined in tools/ e.g. libLLVM, libLTO. I'm defining
"Component Libraries" as libraries defined in lib/ that may be included in
libLLVM.so. Explicitly marking the libraries in lib/ as component
libraries allows us to remove some fragile checks that attempt to
differentiate between lib/ libraries and tools/ libraires:
1. In tools/llvm-shlib, because
llvm_map_components_to_libnames(LIB_NAMES "all") returned a list of
all libraries defined in the whole project, there was custom code
needed to filter out libraries defined in tools/, none of which should
be included in libLLVM.so. This code assumed that any library
defined as static was from lib/ and everything else should be
excluded.
With this change, llvm_map_components_to_libnames(LIB_NAMES, "all")
only returns libraries that have been added to the LLVM_COMPONENT_LIBS
global cmake property, so this custom filtering logic can be removed.
Doing this also fixes the build with BUILD_SHARED_LIBS=ON
and LLVM_BUILD_LLVM_DYLIB=ON.
2. There was some code in llvm_add_library that assumed that
libraries defined in lib/ would not have LLVM_LINK_COMPONENTS or
ARG_LINK_COMPONENTS set. This is only true because libraries
defined lib lib/ use LLVMBuild.txt and don't set these values.
This code has been fixed now to check if the library has been
explicitly marked as a component library, which should now make it
easier to remove LLVMBuild at some point in the future.
I have tested this patch on Windows, MacOS and Linux with release builds
and the following combinations of CMake options:
- "" (No options)
- -DLLVM_BUILD_LLVM_DYLIB=ON
- -DLLVM_LINK_LLVM_DYLIB=ON
- -DBUILD_SHARED_LIBS=ON
- -DBUILD_SHARED_LIBS=ON -DLLVM_BUILD_LLVM_DYLIB=ON
- -DBUILD_SHARED_LIBS=ON -DLLVM_LINK_LLVM_DYLIB=ON
Reviewers: beanz, smeenai, compnerd, phosek
Reviewed By: beanz
Subscribers: wuzish, jholewinski, arsenm, dschuff, jyknight, dylanmckay, sdardis, nemanjai, jvesely, nhaehnle, mgorny, mehdi_amini, sbc100, jgravelle-google, hiraditya, aheejin, fedor.sergeev, asb, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, jrtc27, MaskRay, zzheng, edward-jones, atanasyan, steven_wu, rogfer01, MartinMosbeck, brucehoult, the_o, dexonsmith, PkmX, jocewei, jsji, dang, Jim, lenary, s.egerton, pzheng, sameer.abuasal, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D70179
Summary:
when building plugins, as AIX has symbols in it's standard library that
must be garbage collected or we will see link errors. Export lists will
handle this instead on AIX.
Reviewers: stevewan, sfertile, jasonliu, xingxue, DiggerLin
Reviewed By: DiggerLin
Subscribers: mgorny, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D70130
Summary:
this allows us to move logic about when it is appropriate set
LLVM_NO_DEAD_STRIP out of each tool and into add_llvm_executable,
which will enable future platform specific handling.
This is a follow on to the reverted D69356
Reviewers: hubert.reinterpretcast, beanz, lhames
Reviewed By: beanz
Subscribers: mgorny, cfe-commits, llvm-commits
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D69638
Also add the aliases for these tools so that
LLVM_INSTALL_BINUTILS_SYMLINKS and LLVM_INSTALL_TOOLCHAIN_ONLY can work
together.
Differential Revision: https://reviews.llvm.org/D69635
Summary:
The variable LLVM_NO_DEAD_STRIP is set in LLVM cmake files when building executables that might make use of plugins .The name of the variable does not convey the actual intended usage (i.e. for use with tools that have plugins), just what the eventual effect of setting in on some (i.e. not garbage collecting unused symbols).
This patch renames it to LLVM_SUPPORT_PLUGINS to convey the intended usage, which will allow subsequent patches to add behavior to support that in different ways without confusion about whether it will do on, for example, non-gnu platforms.
Reviewers: hubert.reinterpretcast, stevewan
Reviewed By: stevewan
Subscribers: cfe-commits, mgorny, llvm-commits
Tags: #llvm, #clang
Differential Revision: https://reviews.llvm.org/D69356
Summary: If you are generating an object library that depends on table-gen generate sources, you need the object library to depend on the tablgen target. Currently llvm_add_library doesn't add dependencies for object libraries at all, which is clearly problematic.
Reviewers: compnerd, hintonda, smeenai
Reviewed By: smeenai
Subscribers: mgorny, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D65818
llvm-svn: 368074
Summary:
This patch maps in the `-qnoeh` and `-qnortti` options for building with
IBM XL compilers.
Reviewers: daltenty, xingxue, jasonliu
Reviewed By: daltenty
Subscribers: mgorny, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D65669
llvm-svn: 368050
Summary:
Other platforms don't have the capability to perform llvm_codesign
step. If LLVM_CODESIGNING_IDENTITY is set then this chunk of code would
attempt to codesign if the target was Apple. But when cross compiling
to Darwin from Linux, for example, this step would fail. So test if the
host is Apple as well.
Subscribers: mgorny, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D64942
llvm-svn: 366498
Summary:
This will simplify the macros by allowing us to remove the hard-coded
list of libraries that should be installed when
LLVM_INSTALL_TOOLCHAIN_ONLY is enabled.
Reviewers: beanz, smeenai
Reviewed By: beanz
Subscribers: aheejin, mehdi_amini, mgorny, steven_wu, dexonsmith, cfe-commits, llvm-commits
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D64580
llvm-svn: 365902
Summary:
CMake+Xcode doesn't seem to handle targets that only have object
sources. This patch works around that limitation by adding a dummy
soruce file to any library target that is generated by llvm_add_library
when object libraries are generated.
Object libraries are generated whenever llvm_add_library is passed more
than one library type, which is now the default case for clang static
libraries (which generate STATIC and OBJECT libraries).
Reviewers: zturner, compnerd, joanlluch
Reviewed By: joanlluch
Subscribers: joanlluch, xbolva00, mgorny, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D64300
llvm-svn: 365365
This is a follow up to D56781, D56774 and D35077 to makes the LLVM-C.dll
file and LLVM-C.lib be installed on Windows, just like LTO.dll and
LTO.lib are.
Patch by Jakob Bornecrantz!
Differential revision: https://reviews.llvm.org/D63717
llvm-svn: 364275
Add `nm` and `objcopy` to the default value for the tools that we install now
that they are sufficiently feature complete to replace bintuils' implementation.
Patch by Jiang Yi!
llvm-svn: 362425
This feeds the new llvm_codsign BUNDLE_PATH option through from the llvm target wrapper functions, so that you can specify the BUNDLE_PATH on the target's codesign.
llvm-svn: 362248
Summary:
Clangd's framework is assembled by copying binaries from the lib and bin directories into a bundle shape. This results in an invalid bundle code signature because the signature only applies to the binaries not the resources.
This patch adds two new options to `llvm_codesign` to enable re-signing the library and XPC service as bundles.
The `BUNDLE_PATH` option allow specifying an explicit path to codesign, which enables signing bundles which aren't generated using CMake's `FRAMEWORK` or `BUNDLE` target properties.
The `FORCE` option allows re-signing binaries that have already been signed. This is required for how clangd exposes the clangd library and tools as both XPC and non-XPC services using the same binary.
Reviewers: jkorous, bogner
Reviewed By: bogner
Subscribers: mgorny, ilya-biryukov, dexonsmith, arphaman, kadircet, cfe-commits, llvm-commits
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D62693
llvm-svn: 362169
Summary:
clang and newer versions of ninja use high-resolutions timestamps, but
older versions of libtool on Darwin don't, so the archive will often
get an older timestamp than the last object that was added or updated.
To fix this, we add a custom command to touch the archive after it's
been built so that ninja won't rebuild it unnecessarily the next time
it's run.
Reviewed By: beanz
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D62172
llvm-svn: 361280
This addresses an issue introduced in r360230 which broke existing
use cases of LLVM_DISTRIBUTION_COMPONENTS since ARCHIVE and LIBRARY
target types are no longer handled as components.
Differential Revision: https://reviews.llvm.org/D62176
llvm-svn: 361223
Simplify the cmake logic to install both runtime and import
libraries (treated as ARCHIVE), as the later are needed to link
against llvm.
Patch by Julien Schueller!
Differential Revision: https://reviews.llvm.org/D61425
llvm-svn: 360230
The unwind tables (`.eh_frame`, `.arm.extab`) add a significant chunk of data to
the final binaries. These should not be needed normally, particularly when
exceptions are disabled. This enables shrinking `lldb-server` by ~18% (3 MiB)
when built with gold.
llvm-svn: 359819
This is required for using PGO on Windows but isn't in the Windows
release packages. Windows packages are built with
LLVM_INSTALL_TOOLCHAIN_ONLY so only includes llvm "tools" listed here.
Differential Revision: https://reviews.llvm.org/D61317
llvm-svn: 359569
Summary:
The CMake documentation says that the `DEPENDS` field of
add_custom_target is for files and output of custom commands. Adding a
dependency on a target should be done with `add_dependency`.
Differential Revision: https://reviews.llvm.org/D60879
llvm-svn: 359042
Summary:
Extra flexibility for emitting debug info to external files (remains Darwin only for now).
LLDB needs this functionality to emit a LLDB.framework.dSYM instead of LLDB.dSYM when building the framework, because the latter could conflict with the driver's lldb.dSYM when emitted in the same directory on case-insensitive file systems.
Reviewers: friss, bogner, beanz
Subscribers: mgorny, aprantl, llvm-commits, #lldb
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D60862
llvm-svn: 358685
