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
A bunch of macros use the same variable name, and since CMake macros
don't get their own scope, the value persists across macro invocations,
and we can end up exporting targets which shouldn't be exported. Clear
the variable before each use to avoid this.
Converting these macros to functions would also help, since it would
avoid the variable leaking into its parent scope, and that's something I
plan to follow up with. It won't fully address the problem, however,
since functions still inherit variables from their parent scopes, so if
someone in the parent scope just happened to use the same variable name
we'd still have the same issue.
llvm-svn: 357036
Summary:
This wasn't actually printing out a CMake warning, it was prepending
"WARN" to the message.
Reviewers: zturner
Subscribers: mgorny, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D59432
llvm-svn: 356297
Summary:
In support of IBM's efforts to produce a viable C and C++ LLVM compiler for AIX
(ref: RFC at http://lists.llvm.org/pipermail/llvm-dev/2019-February/130175.html),
this patch adds customizations to the CMake files in order to properly
invoke the host toolchain for the build on AIX.
Additional changes to enable a successful build will follow.
Patch by Xing Xue
Reviewers: hubert.reinterpretcast, jasonliu, sfertile
Reviewed by: hubert.reinterpretcast
Differential Revision: https://reviews.llvm.org/D58250
llvm-svn: 356104
Getting rid of the name "optimization remarks" for anything that
involves handling remarks on the client side.
It's safer to do this now, before we get stuck with that name in all the
APIs and public interfaces we decide to export to users in the future.
This renames llvm/tools/opt-remarks to llvm/tools/remarks-shlib, and now
generates `libRemarks.dylib` instead of `libOptRemarks.dylib`.
Differential Revision: https://reviews.llvm.org/D58535
llvm-svn: 355439
When using the umbrella llvm-libraries and clang-libraries targets, we
should export all library targets, otherwise they'll be part of our
distribution but not usable from the CMake package.
Differential Revision: https://reviews.llvm.org/D58862
llvm-svn: 355354
Summary:
Handle the case where LLVM_MAIN_SRC_DIR is not set and also use
LLVM_CMAKE_DIR for locating installed cmake files rather than
LLVM_CMAKE_PATH.
Reviewers: phosek, andrewrk, smeenai
Reviewed By: phosek, andrewrk, smeenai
Subscribers: mgorny, cfe-commits, llvm-commits
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D58204
llvm-svn: 354417
Previously, there were two different scripts for generating VCS headers:
one used by LLVM and one used by Clang and lldb. They were both similar,
but different. They were both broken in their own ways, for example the
one used by Clang didn't properly handle monorepo resulting in an
incorrect version information reported by Clang.
This change unifies two the scripts by introducing a new script that's
used from both LLVM, Clang and lldb, ensures that the new script
supports both monorepo and standalone SVN and Git setups, and removes
the old scripts.
Differential Revision: https://reviews.llvm.org/D57063
llvm-svn: 353268
Summary: D56606 was only appending target names to the `LLVM_EXPORTS`/`LLVM_EXPORTS_BUILDTREE_ONLY` properties. Targets showed up correctly in the build-tree `LLVMExports.cmake`, but they were missing in the installed one (as we found in https://bugs.llvm.org/show_bug.cgi?id=40443), because install did not register them explicitly.
Reviewers: mgorny, smeenai, beanz, gottesmm, dschuff, tstellar, serge-sans-paille
Reviewed By: smeenai
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D57383
llvm-svn: 352869
Previously, there were two different scripts for generating VCS headers:
one used by LLVM and one used by Clang. They were both similar, but
different. They were both broken in their own ways, for example the one
used by Clang didn't properly handle monorepo resulting in an incorrect
version information reported by Clang.
This change unifies two the scripts by introducing a new script that's
used from both LLVM and Clang, ensures that the new script supports both
monorepo and standalone SVN and Git setups, and removes the old scripts.
Differential Revision: https://reviews.llvm.org/D57063
llvm-svn: 352729
Summary: We added support for code signing entitlements in add_llvm_executable() with D54443. In the future it would be useful to have this functionality available also for libraries.
Reviewers: beanz, bogner
Reviewed By: bogner
Subscribers: mgorny, llvm-commits, lldb-commits, #lldb
Differential Revision: https://reviews.llvm.org/D57334
llvm-svn: 352628
Refactor the get_llvm_lit_path() logic to respect LLVM_EXTERNAL_LIT,
and require the fallback to be defined explicitly
as LLVM_DEFAULT_EXTERNAL_LIT. This fixes building libcxx standalone
after r346888.
The old logic was using LLVM_EXTERNAL_LIT both as user-defined cache
variable and an optional pre-definition of default value from caller
(e.g. libcxx). It included a hack to make this work by assigning
the value back and forth but it was fragile and stopped working
in libcxx.
The new logic is simpler and more transparent. Default value is
provided in a separate variable, and used only when user-specified
variable is empty (i.e. not overriden).
Differential Revision: https://reviews.llvm.org/D57282
llvm-svn: 352374
Summary:
Allow external projects to import test-related targets like FileCheck, count, not etc. and query binary paths, properties, etc.
This would be useful for LLDB, because it reduces the difference between in-tree vs. standalone builds and simplifies CMake logic.
Reviewers: chapuni, gottesmm, beanz
Reviewed By: beanz
Subscribers: mgorny, lldb-commits, llvm-commits, #lldb
Differential Revision: https://reviews.llvm.org/D56606
llvm-svn: 350959
Summary: A post-commit comment to D55116 amended that this was the correct way for code signing in Xcode.
Reviewers: beanz
Reviewed By: beanz
Subscribers: mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D55816
llvm-svn: 350383
Summary:
This function is very similar to add_llvm_library(), so this patch merges it
into add_llvm_library() and replaces all calls to add_llvm_loadable_module(lib ...)
with add_llvm_library(lib MODULE ...)
Reviewers: philip.pfaffe, beanz, chandlerc
Reviewed By: philip.pfaffe
Subscribers: chapuni, mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D51748
llvm-svn: 349839
Summary:
When using Xcode to build LLVM with code signing, the post-build rule is executed even if the actual build-step was skipped. This causes double-signing errors. We can currently only avoid it by passing the `--force` flag.
Plus some polishing for my previous patch D54443.
Reviewers: beanz, kubamracek
Reviewed By: kubamracek
Subscribers: #lldb, mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D55116
llvm-svn: 349070
Summary:
Allow clients to suppress setup of default RPATHs in designated library targets. This is used in LLDB when emitting liblldb as a framework bundle, which itself doesn't load further RPATH-dependent libraries.
This follows the approach in add_llvm_executable().
Reviewers: aprantl, JDevlieghere, davide, friss
Reviewed By: aprantl
Subscribers: mgorny, lldb-commits, llvm-commits, #lldb
Differential Revision: https://reviews.llvm.org/D55316
llvm-svn: 348573
I found the pattern of setting the project_BUILD variable to OFF after
processing the project to be pretty confusing. Using global properties
to explicitly keep track of whether a project has been processed or not
seems much more straightforward, and it also allows us to convert the
macro into a function (which is required for the early return).
Factor the project+type+name combination out into a variable while I'm
here, since it's used a whole bunch of times.
I don't believe this should result in any functional changes.
Differential Revision: https://reviews.llvm.org/D55104
llvm-svn: 348180
Summary: When using `LLVM_EXTERNALIZE_DEBUGINFO` in LLDB, the default dSYM location for the shared library in LLDB.framework is inside the framework bundle. With `LLVM_EXTERNALIZE_DEBUGINFO_OUTPUT_DIR` we can easily fix that. I consider it a useful feature to be able to set a global output directory for external debug info (rather then having a target-specific one). Only implemented for Darwin so far.
Reviewers: beanz, aprantl
Reviewed By: aprantl
Subscribers: mgorny, aprantl, #lldb, lldb-commits, llvm-commits
Differential Revision: https://reviews.llvm.org/D55114
llvm-svn: 348118
The add_llvm_symbol_exports function in AddLLVM.cmake creates command
line link flags with paths containing CMAKE_CURRENT_BINARY_DIR, but that
will break if CMAKE_CURRENT_BINARY_DIR contains whitespace. This patch
adds quotes to those paths.
Fixes PR39843.
Patch by John Garvin.
Differential Revision: https://reviews.llvm.org/D55081
llvm-svn: 347937
Summary:
It will cause test tools `FileCheck`, `count`, `not` being built blindly, these
dependencies should move back to clang-tools-extra.
Reviewers: mgorny
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D54797
llvm-svn: 347448
Summary: Allow code-signing with entitlements. FORCE may be used to avoid an error when replacing existing signatures.
Reviewers: beanz, bogner
Reviewed By: beanz
Subscribers: mgorny, llvm-commits, lldb-commits
Differential Revision: https://reviews.llvm.org/D54443
llvm-svn: 347068
* Create an install target for it
* Add it under tools/opt-remarks
* Add an export file for the dylib
* Install the llvm-c/OptRemarks.h header
* Add an API to query its version
rdar://45458839
llvm-svn: 346127
There are several places where we use CMAKE_CONFIGURATION_TYPES to determine if we are using an IDE generator and in turn decide not to generate some of the convenience targets (like all the install-* and check-llvm-* targets). This decision is made because IDEs don't always deal well with the thousands of targets LLVM can generate.
This approach does not work for Visual Studio 15's new CMake integration. Because VS15 uses a Ninja generator, it isn't a multi-configuration build, and generating all these extra targets mucks up the UI and adds little value.
With this change we still don't generate these targets by default for Visual Studio and Xcode generators, and LLVM_ENABLE_IDE becomes a switch that can be enabled on the VS15 CMake builds, to improve the IDE experience.
This is a re-land of r340435, with a few minor fix-ups. The issues causing the revert were addressed in r344218, r344219, and r344553.
llvm-svn: 344555
Summary:
Address fixme in r301762. And would simplify the cmake file in
clang-tools-extra.
Reviewers: sammccall
Subscribers: mgorny, llvm-commits, cfe-commits
Differential Revision: https://reviews.llvm.org/D52713
llvm-svn: 343473
Using llvm::getInputFileDirectory() in unit tests is discouraged, so require an explicit opt-in.
This way, cmake also writes ~60 fewer unused files to disk.
Differential Revision: https://reviews.llvm.org/D52095
llvm-svn: 342248
We can't put the unittest source dir map in the configuration
specific directory because VS doesn't have a configure-specific
directory, instead it only knows this at runtime. So we have
to remove this from the path. This in turn means that the path
will be slightly different in VS configurations vs non vs
configurations. In the former, the source map will be in the
parent directory of the executable, and in the latter it will
be in the same directory as the executable. So check both.
llvm-svn: 341590
Occasionally it is useful to have unittest which take inputs.
While we normally try to have this test be more of a lit test
we occasionally don't have tools that can exercise the code
in the right way to test certain things. LLDB has been using
this style of unit test for a while, particularly with regards
to how it tests core dump and minidump file parsing. Recently
i needed this as well for the case where we want to test that
some of the PDB reading code works correctly. It needs to
exercise the code in a way that is not covered by any dumper
and would be impractical to implement in one of the dumpers,
but requires a valid PDB file. Since this is now needed by
more than one project, it makes sense to have this be a
generally supported thing that unit tests can do, and we just
encourage people to use this sparingly.
Differential Revision: https://reviews.llvm.org/D51561
llvm-svn: 341502
It's always replaced with the same (short) static string, so just put that
there directly.
No intended behavior change.
https://reviews.llvm.org/D51357
llvm-svn: 341135
That resulted in the check-llvm-* targets not being avaliable
in the QtCreator-configured build directories.
Moreover, that was a clearly non-NFC change, and i can't find any review
for it.
This reverts commit rL340435.
llvm-svn: 341045
This patch pulls google/benchmark v1.4.1 into the LLVM tree so that any
project could use it for benchmark generation. A dummy benchmark is
added to `llvm/benchmarks/DummyYAML.cpp` to validate the correctness of
the build process.
The current version does not utilize LLVM LNT and LLVM CMake
infrastructure, but that might be sufficient for most users. Two
introduced CMake variables:
* `LLVM_INCLUDE_BENCHMARKS` (`ON` by default) generates benchmark
targets
* `LLVM_BUILD_BENCHMARKS` (`OFF` by default) adds generated
benchmark targets to the list of default LLVM targets (i.e. if `ON`
benchmarks will be built upon standard build invocation, e.g. `ninja` or
`make` with no specific targets)
List of modifications:
* `BENCHMARK_ENABLE_TESTING` is disabled
* `BENCHMARK_ENABLE_EXCEPTIONS` is disabled
* `BENCHMARK_ENABLE_INSTALL` is disabled
* `BENCHMARK_ENABLE_GTEST_TESTS` is disabled
* `BENCHMARK_DOWNLOAD_DEPENDENCIES` is disabled
Original discussion can be found here:
http://lists.llvm.org/pipermail/llvm-dev/2018-August/125023.html
Reviewed by: dberris, lebedev.ri
Subscribers: ilya-biryukov, ioeric, EricWF, lebedev.ri, srhines,
dschuff, mgorny, krytarowski, fedor.sergeev, mgrang, jfb, llvm-commits
Differential Revision: https://reviews.llvm.org/D50894
llvm-svn: 340809
There are several places where we use CMAKE_CONFIGURATION_TYPES to determine if we are using an IDE generator and in turn decide not to generate some of the convenience targets (like all the install-* and check-llvm-* targets). This decision is made because IDEs don't always deal well with the thousands of targets LLVM can generate.
This approach does not work for Visual Studio 15's new CMake integration. Because VS15 uses a Ninja generator, it isn't a multi-configuration build, and generating all these extra targets mucks up the UI and adds little value.
With this change we still don't generate these targets by default for Visual Studio and Xcode generators, and LLVM_ENABLE_IDE becomes a switch that can be enabled on the VS15 CMake builds, to improve the IDE experience.
llvm-svn: 340435
llvm-strip doesn't handle -gx spelling, so we need to split these
as two separate flags.
Differential Revision: https://reviews.llvm.org/D50684
llvm-svn: 339639
Append LLVM_VERSION_SUFFIX to SOVERSION. This makes it possible
to use the suffix to differentiate binary-incompatible versions
of LLVM built via BUILD_SHARED_LIBS.
We are planning to use this to temporarily preserve ABI-incompatible
variants of LLVM while switching the system between them, e.g. when
rebuilding the system to use libc++. Normally this would mean that once
LLVM is rebuilt using libc++ all the reverse dependencies become
immediately broken. Using a distinct SOVERSION allows us to preserve
the ABI compatibility before all the packages are rebuilt.
Differential Revision: https://reviews.llvm.org/D39939
llvm-svn: 339286
Automatically codesign all executables and dynamic libraries if a
codesigning identity is given (via LLVM_CODESIGNING_IDENTITY). This
option is darwin only for now.
Also update platforms/iOS.cmake to pick up the right versions of
codesign and codesign_allocate.
llvm-svn: 336708
The test is about what can be run on the host, not the cmake target.
When cross-compiling (compiler-rt at least) on Windows, we end up with
lit being unable to run llvm-lit because it can't find the llvm-lit
module.
llvm-svn: 335961
This allows overriding the strip and dsymutil tools, and updates
iOS.cmake to do so. I've also added libtool to iOS.cmake, but it was
already respecting CMAKE_LIBTOOL if set.
llvm-svn: 335900
LLVM currently assumes that Apple platforms will always use ld64. In the
future, LLD Mach-O might also be supported, so add the beginnings of
linker detection support. ld64 is currently the only detected linker,
since `ld64.lld -v` doesn't yield any useful version output, but we can
add that detection later, and in the meantime it's still useful to have
the ld64 identification.
Switch clang's order file check to use this new detection rather than
just checking for the presence of an ld64 executable.
Differential Revision: https://reviews.llvm.org/D48201
llvm-svn: 334780
Don't hardcode objcopy and strip names, rather use CMAKE_OBJCOPY and
CMAKE_STRIP variables which allows users to override the tools used
such as using llvm-objcopy and llvm-strip instead of binutils versions.
Differential Revision: https://reviews.llvm.org/D46611
llvm-svn: 331827
LLVM might be compiled using a toolchain file which controls the linker
to use via flags (e.g. `-B` or `-fuse-ld=`). Take these flags into
account for linker detection. We can also correct the detection by
manually passing LLVM_USE_LINKER, of course, but it seems more
convenient to have the detection take flags into account.
Differential Revision: https://reviews.llvm.org/D45464
llvm-svn: 330924
Virtually all other tablegen outputs are called .inc, not .gen, so rename these two too for consistency.
No behavior change.
https://reviews.llvm.org/D46058
llvm-svn: 330843
Summary:
As we are only doing X.0.Z releases (not using the minor version), there is no need to keep -X.Y in the version.
Like patch https://reviews.llvm.org/D41808, I propose that we rename libLLVM-7.0svn.so to libLLVM-7svn.so
This patch will also rename downstream libraries like liblldb-7.0 to liblldb-7
Reviewers: axw, beanz, dim, hans
Reviewed By: dim, hans
Subscribers: mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D41869
llvm-svn: 328768
Append -Wl,-rpath-link conditionally to whether GNU ld.bfd is used
rather than the Linux+!gold conditionals. Also move it out of 'else'
branch of *BSD handling. This fixes build failures with ld.bfd
on Gentoo/FreeBSD, and should cause no harm on other systems using
ld.bfd.
This patch improves the original logic by reusing results of linker
detection introduced in r307852.
Differential Revision: https://reviews.llvm.org/D43751
llvm-svn: 327007
When cross-compiling for Windows on Unix, the built toolchain will need
to be transferred to Windows to actually run. My opinion is that the
Unix build should use symlinks, and the transfer to Windows should take
care of making those symlinks usable. E.g., I envision tarballs to be a
common form of transfer from Unix to Windows, in which case the tarball
can be created using --dereference to follow the symlinks.
The motivation here is that, when cross-compiling for Windows on Unix,
the installation will *already* create symlinks. The reason is that the
installation script will be invoked without knowing the host system, so
the `if(UNIX)` check in the installation symlink creation script will
reflect the build system rather than the host system. We could either
make the build and install trees both contain copies or both contain
symlinks, and using symlinks is a significant space saving without (in
my opinion) having any detrimental effect on the usage of the cross-
compiled toolchain on Windows.
A secondary motivation is that Windows 10 version 1703 and later finally
lift the administrator rights requirement for creating symbolic links
(if the system is in Developer Mode), which makes symlinks a lot more
practical even on Windows. Of course Unix and Windows symlinks aren't
interoperable, but symlinks for Windows toolchains is a reasonable
future direction to be going in anyway.
Differential Revision: https://reviews.llvm.org/D41314
llvm-svn: 322061
We currently use target_link_libraries without an explicit scope
specifier (INTERFACE, PRIVATE or PUBLIC) when linking executables.
Dependencies added in this way apply to both the target and its
dependencies, i.e. they become part of the executable's link interface
and are transitive.
Transitive dependencies generally don't make sense for executables,
since you wouldn't normally be linking against an executable. This also
causes issues for generating install export files when using
LLVM_DISTRIBUTION_COMPONENTS. For example, clang has a lot of LLVM
library dependencies, which are currently added as interface
dependencies. If clang is in the distribution components but the LLVM
libraries it depends on aren't (which is a perfectly legitimate use case
if the LLVM libraries are being built static and there are therefore no
run-time dependencies on them), CMake will complain about the LLVM
libraries not being in export set when attempting to generate the
install export file for clang. This is reasonable behavior on CMake's
part, and the right thing is for LLVM's build system to explicitly use
PRIVATE dependencies for executables.
Unfortunately, CMake doesn't allow you to mix and match the keyword and
non-keyword target_link_libraries signatures for a single target; i.e.,
if a single call to target_link_libraries for a particular target uses
one of the INTERFACE, PRIVATE, or PUBLIC keywords, all other calls must
also be updated to use those keywords. This means we must do this change
in a single shot. I also fully expect to have missed some instances; I
tested by enabling all the projects in the monorepo (except dragonegg),
and configuring both with and without shared libraries, on both Darwin
and Linux, but I'm planning to rely on the buildbots for other
configurations (since it should be pretty easy to fix those).
Even after this change, we still have a lot of target_link_libraries
calls that don't specify a scope keyword, mostly for shared libraries.
I'm thinking about addressing those in a follow-up, but that's a
separate change IMO.
Differential Revision: https://reviews.llvm.org/D40823
llvm-svn: 319840
CMake's generated installation scripts support `CMAKE_INSTALL_DO_STRIP`
to enable stripping the installed binaries. LLVM's build system doesn't
expose this option to the `install-` targets, but it's useful in
conjunction with `install-distribution`.
Add a new function to create the install targets, which creates both the
regular install target and a second install target that strips during
installation. Change the creation of all installation targets to use
this new function. Stripping doesn't make a whole lot of sense for some
installation targets (e.g. the LLVM headers), but consistency doesn't
hurt.
I'll make other repositories (e.g. clang, compiler-rt) use this in a
follow-up, and then add an `install-distribution-stripped` target to
actually accomplish the end goal of creating a stripped distribution. I
don't want to do that step yet because the creation of that target would
depend on the presence of the `install-*-stripped` target for each
distribution component, and the distribution components from other
repositories will be missing that target right now.
Differential Revision: https://reviews.llvm.org/D40620
llvm-svn: 319480
In recent versions of Solaris 11.4 (previously 12), ld -V output went to
stdout instead of stderr. Since AddLLVM.cmake only expects it on stderr,
Solaris ld wasn't properly detected and options not understood by it are
passed during the build.
The following patch fixes this, allowing for both variants.
Tested on i386-pc-solaris2.11.4 (on top of D35755 which is needed for
proper Solaris support).
Patch by Rainer Orth.
Differential Revision: https://reviews.llvm.org/D39601
llvm-svn: 318532
Fix linker not being correctly detected when a custom one is specified
through LLVM_USE_LINKER CMake variable.
In particular,
cmake -DCMAKE_BUILD_TYPE=Release -DLLVM_USE_LINKER=gold ../llvm
resulted into
Linker detection: GNU ld
instead of
Linker detection: GNU Gold
due to the construction not accounting for such variable. It led to the general
confusion and prevented setting linker-specific flags inside functions defined
in AddLLVM.cmake.
Thanks Oleksii Vilchanskyi for the patch!
llvm-svn: 316956
gtest depends on this #define to determine whether it can
use various classes like std::tuple, or whether it has to fall
back to experimental classes in the std::tr1 namespace. The
check in the current version of gtest relies on the value of
the `__cplusplus` macro, but MSVC provides a non-conformant
value of this macro, making it effectively impossible to detect
C++11. In short, LLVM compiled with MSVC has been silently
using the tr1 versions of several classes since the beginning of
time.
This would normally be pretty benign, except that in the latest
preview of MSVC they have marked all of the tr1 classes
deprecated, so it spews thousands of warnings.
llvm-svn: 316798
Summary:
It appears polly makes use of the `CMAKE_RUNTIME_OUTPUT_DIRECTORY` variable
when configuring its lit test suite. Reverting this for now.
llvm-svn: 314551
Summary:
Three `CMAKE_.*_OUTPUT_DIRECTORY` variables used to be set in CMake and
referenced in various other parts of the project. However, in r198205
chapuni added a note to "don't set them anymore", and any remaining
references to them were subsequently removed in r198316 and r199592.
Now that the variables are no longer used anywhere, remove them, along
with the comments advising against using them any longer.
Test Plan:
I ran `check-all` and confirmed the tests built and passed.
Reviewers: beanz, chapuni
Reviewed By: beanz
Subscribers: mgorny
Differential Revision: https://reviews.llvm.org/D38389
llvm-svn: 314550
Config map is not exposed through the command line, so testing this
is somewhat tricky. But basically we need a test that if a custom
driver builds a config map and passes it to main, it gets respected.
A config map allows config files in the source tree to be mapped
to alternate config files in the build tree. This particular test
works by having two config files in separate directories, and
setting up a config map to have that redirects A/lit.site.cfg
to B/altconfig. Then, we print a message in A/lit.site.cfg
and B/altconfig and check that we do see the output from B
but don't see the output from A. Additionally we test that
the test suite specified by A's config map is properly discovered.
Differential Revision: https://reviews.llvm.org/D38105
llvm-svn: 313887
Many editors and Python-related diagnostics tools such as
debuggers break or fail in mysterious ways when python files
don't end in .py. This is especially true on Windows, but
still exists on other platforms. I don't want to be too heavy
handed in changing everything across the board, but I do want
to at least *allow* lit configs to have .py extensions. This
patch makes the discovery process first look for a config file
with a .py extension, and if one is not found, then looks for
a config file using the old method. So for existing users, there
should be no functional change.
Differential Revision: https://reviews.llvm.org/D37838
llvm-svn: 313849
Despite a strong CMake warning that this is an unsupported
libcxx build configuration, some bots still rely on being
able to check out lit and libcxx independently with no
LLVM sources, and then run lit against libcxx.
A previous patch broke that workflow, so this is making it work
again. Unfortunately, it breaks generation of the llvm-lit
script for libcxx, but we will just have to live with that until
a solution is found that allows libcxx to make more use of
llvm build pieces. libcxx can still run tests by using the
ninja check target, or by running lit.py directly against the
build tree or source tree.
Differential Revision: https://reviews.llvm.org/D38057
llvm-svn: 313763
After speaking with the libcxx owners, they agreed that this is
a bug in the bot that needs to be fixed by the bot owners, and
the CMake changes are correct.
llvm-svn: 313643
This reverts commit 4ad71811d45268d81b60f27e3b8b2bcbc23bd7b9.
There is a bot that is checking out libcxx and lit with nothing
else and then running lit.py against the test tree. Since there's
no LLVM source tree, there's no LLVM CMake. CMake actually
reports this as a warning saying unsupported libcxx configuration,
but I guess someone is depending on it anyway.
llvm-svn: 313607
It looks like this is going to be non-trivial to get working
in both Py2 and Py3, so for now I'm reverting until I have time
to fully test it under Python 3.
llvm-svn: 313429
This is a resubmission of r313270. It broke standalone builds of
compiler-rt because we were not correctly generating the llvm-lit
script in the standalone build directory.
The fixes incorporated here attempt to find llvm/utils/llvm-lit
from the source tree returned by llvm-config. If present, it
will generate llvm-lit into the output directory. Regardless,
the user can specify -DLLVM_EXTERNAL_LIT to point to a specific
lit.py on their file system. This supports the use case of
someone installing lit via a package manager. If it cannot find
a source tree, and -DLLVM_EXTERNAL_LIT is either unspecified or
invalid, then we print a warning that tests will not be able
to run.
Differential Revision: https://reviews.llvm.org/D37756
llvm-svn: 313407
This patch is still breaking several multi-stage compiler-rt bots.
I already know what the fix is, but I want to get the bots green
for now and then try re-applying in the morning.
llvm-svn: 313335
To further reduce duplicate code, this patch introduces a module
that configs can simply import and get access to a lot of useful
functionality such as setting up paths, adding features that are
useful across all projects, and other utility-type functions.
For now this only updates llvm's suite to use this new library,
but subsequent patches will update other projects.
Differential Revision: https://reviews.llvm.org/D37778
llvm-svn: 313325
This patch simplifies LLVM's lit infrastructure by enforcing an ordering
that a site config is always run before a source-tree config.
A significant amount of the complexity from lit config files arises from
the fact that inside of a source-tree config file, we don't yet know if
the site config has been run. However it is *always* required to run
a site config first, because it passes various variables down through
CMake that the main config depends on. As a result, every config
file has to do a bunch of magic to try to reverse-engineer the location
of the site config file if they detect (heuristically) that the site
config file has not yet been run.
This patch solves the problem by emitting a mapping from source tree
config file to binary tree site config file in llvm-lit.py. Then, during
discovery when we find a config file, we check to see if we have a
target mapping for it, and if so we use that instead.
This mechanism is generic enough that it does not affect external users
of lit. They will just not have a config mapping defined, and everything
will work as normal.
On the other hand, for us it allows us to make many simplifications:
* We are guaranteed that a site config will be executed first
* Inside of a main config, we no longer have to assume that attributes
might not be present and use getattr everywhere.
* We no longer have to pass parameters such as --param llvm_site_config=<path>
on the command line.
* It is future-proof, meaning you don't have to edit llvm-lit.in to add
support for new projects.
* All of the duplicated logic of trying various fallback mechanisms of
finding a site config from the main config are now gone.
One potentially noteworthy thing that was required to implement this
change is that whereas the ninja check targets previously used the first
method to spawn lit, they now use the second. In particular, you can no
longer run lit.py against the source tree while specifying the various
`foo_site_config=<path>` parameters. Instead, you need to run
llvm-lit.py.
Differential Revision: https://reviews.llvm.org/D37756
llvm-svn: 313270
This was intended to be a generic CMake solution to a problem
shared across several projects. It turns out it doesn't interact
very well certain CMake configurations, and furthermore the
"problem" is actually not a problem, as the problematic code
is never executed to begin with. So this really isn't solving
anything.
llvm-svn: 313191
Some projects need to add conditional dependencies on other projects.
compiler-rt is already doing this, and I attempted to add this to
debuginfo-tests when I ran into the ordering problem, that you can't
conditionally add a dependency unless that dependency's CMakeLists.txt
has already been run (which would allow you to say if (TARGET foo).
The solution to this seems to be to determine very early on the entire
set of projects which is enabled. This is complicated by the fact that
there are multiple ways to enable projects, and different tree layouts
(e.g. mono-repo, out of -tree, external, etc). This patch attempts to
centralize all of this into one place, and then updates compiler-rt to
demonstrate as a proof of concept how this can simplify code.
Differential Revision: https://reviews.llvm.org/D37637
llvm-svn: 313091
FuzzMutate might not be the best place for these, but it makes more
sense than an entirely new library for now. This will make setting up
fuzz targets with consistent CLI handling easier.
llvm-svn: 312425
Summary:
Move version control macros, find_first_existing_file and
find_first_existing_vc_file to AddLLVM.cmake so they can be reused by sub projects
like clang.
Differential Revision: https://reviews.llvm.org/D36971
llvm-svn: 312419
This adds a dummy main so we can build and run the llvm-isel-fuzzer
functionality when we aren't building LLVM with coverage. The approach
here should serve as a template to stop in-tree fuzzers from
bitrotting (See llvm.org/pr34314).
Note that I'll probably move most of the logic in DummyISelFuzzer's
`main` to a library so it's easy to reuse it in other fuzz targets,
but I'm planning on doing that in a follow up that also consolidates
argument handling in our LLVMFuzzerInitialize implementations.
llvm-svn: 312338
This moves the cmake configuration for fuzzers in LLVM to a new macro,
add_llvm_fuzzer. This will make it easier to keep things consistent
while implementing llvm.org/pr34314.
I've also made a couple of minor functional changes here:
- the fuzzers now use add_llvm_executable rather than add_llvm_tool.
This means they won't create install targets and stuff like that,
because those made little sense for these fuzzers.
- I've grouped these under "Fuzzers" rather than in with "Tools" for
people who build with IDEs.
llvm-svn: 312200
Solaris ld is not the only linker available on Solaris.
Introducing linker detection and using LLVM_LINKER_IS_SOLARISLD to
select Solaris-ld specific handling.
Patch by: Fedor Sergeev
Differential Revision: https://reviews.llvm.org/D35325
llvm-svn: 307852
Summary:
This is like the LLVM_TOOLS_INSTALL_DIR option, but for the utils
that are installed when the LLVM_INSTALL_UTILS. This option
defaults to 'bin' to remain consistent with the current behavior, but
distros may want to install these to libexec/llvm.
Reviewers: beanz
Reviewed By: beanz
Subscribers: llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D30655
llvm-svn: 307150
No behavior is changed if LLVM_TARGET_TRIPLE_ENV is blank or undefined.
If LLVM_TARGET_TRIPLE_ENV is "TEST_TARGET_TRIPLE" and $TEST_TARGET_TRIPLE is not blank,
llvm::sys::getDefaultTargetTriple() returns $TEST_TARGET_TRIPLE.
Lit resets config.target_triple and config.environment[LLVM_TARGET_TRIPLE_ENV] to change the default target.
Without changing LLVM_DEFAULT_TARGET_TRIPLE nor rebuilding, lit can be run;
TEST_TARGET_TRIPLE=i686-pc-win32 bin/llvm-lit -sv path/to/test/
TEST_TARGET_TRIPLE=i686-pc-win32 ninja check-clang-tools
Differential Revision: https://reviews.llvm.org/D33662
llvm-svn: 305632
Summary:
This patch adds a very simple linker script to version the lib's symbols
and thus trying to avoid crashes if an application loads two different
LLVM versions (as long as they do not share data between them).
Note that we deliberately *don't* make LLVM_5.0 depend on LLVM_4.0:
they're incompatible and the whole point of this patch is
to tell the linker that.
Avoid unexpected crashes when two LLVM versions are used in the same process.
Author: Rebecca N. Palmer <rebecca_palmer@zoho.com>
Author: Lisandro Damían Nicanor Pérez Meyer <lisandro@debian.org>
Author: Sylvestre Ledru <sylvestre@debian.org>
Bug-Debian: https://bugs.debian.org/848368
Reviewers: beanz, rnk
Reviewed By: rnk
Subscribers: mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D31524
llvm-svn: 300496
Saleem Abdulrasool