This reverts commit bc3f54de18.
The patch breaks in the following two scenarios:
1. When manually passing an absolute path to llvm-lit with a lower-case
drive letter: `python bin\llvm-lit.py -sv c:\llvm-project\clang\test\PCH`
2. When the PWD has a lower-case drive letter, like after running
`cd c:\` with a lower-case "c:" (cmd's default is upper-case, but
it takes case-ness from what's passed to `cd` apparently).
There's been some back and forth if the cfg paths in the
config_map should be normcase()d. The argument for is that
it allows using all-lower spelling in cmd on Windows, the
argument against that doing so is lossy.
Before the relative-paths-in-generated-lit.site.cfg.py work,
there was no downside to calling normcase(), but with it
we need a hack to recover the original case.
This time, normcase() the hashtable key, but store the original
cased key in addition to the value. This fixes both cons, at the
cost of a few bytes more memory.
Differential Revision: https://reviews.llvm.org/D78169
I broke bots last week and tried a few things to fix them.
These were attempts that didn't help, so back them back out.
This reverts commit c7aff9a109.
This reverts commit 8838d6d356.
This reverts commit e875ba1509.
This builds on top of D77184. With this, I can rename my build directory
to a different name and `bin/llvm-lit ../llvm-project/clang/test
../llvm-project/llvm/test` still succeeds.
I haven't tried copying the build dir to a different machine to run
tests there yet, but I tried something like it a few months ago and it
worked back then.
Changes:
- Make configure_lit_site_cfg() store the main / generated config pair
interleaved in the LLVM_LIT_CONFIG_FILES list and postpone converting
it to python code to llvm-lit's CMakeList.
- Pull the relpath code into a new function make_paths_relative() and
call that in llvm-lit's CMakeList, prior to converting the list to
python code.
- Pull the path() function into a variable and use that in llvm-lit's
CMakeList too.
Differential Revision: https://reviews.llvm.org/D77496
When clang is built against a prebuilt LLVM, LLVM_SOURCE_DIR is
empty, which due to a cmake quirk caused list lengths to get out
of sync. Add a workaround.
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
Eli Friedman