OS X 10.11 has a feature named System Integrity Protection. The goal of the feature is to make system binaries immutable (even as root). One part of this is that protected binaries do not receive DYLD_* environment variables because the kernel scrubs them before process launch.
This causes problems for LTO bootstrap builds on Darwin that try to use the just-built libLTO with the host ar, ranlib, or libtool.
This patch addresses two problems.
(1) The tools themselves aren't protected binaries but the shim tools installed at / are, so we need to call xcrun -find to find libtool instead of using the one CMake finds.
(2) Some build tools (ninja and make) use /bin/sh to invoke their subprocesses. Since /bin/sh is a system binary, the kernel scrubs the DYLD envars from their environment. To work around this we need to set the environment variables as part of the archiver commands, so the envars are set by the shell process instead of on the shell process.
llvm-svn: 276710
It's been pointed out that arbitrarily spraying raw profiles into a
build directory is insane. Doing this wastes a tremendous amount of
space and is also very lossy, since the test harness tends to wipe away
temporary sub-directories (which usually contain relevant profile data).
The new default is a `profiles` directory inside of the build dir.
llvm-svn: 276504
This does not change anything by default since LLVM_INCLUDE_UTILS is already set
to TRUE by default. In addition, since LLVM_INCLUDE_TESTS => LLVM_INCLUDE_UTILS,
the only way that this can cause changes is in the case where LLVM_INCLUDE_UTILS
is set to TRUE, but LLVM_INCLUDE_TESTS is FALSE. In that case, building gtest is
not a huge cost.
The reason to do this is that without this change, one can not turn off
LLVM_INCLUDE_TESTS in downstream projects that also use gtest for unittests. It
also just in general makes more sense since LLVM_INCLUDE_UTILS gates FileCheck
and other utilities that are along the lines of gtest.
Additionally from talking with chandlerc, this was not done for any specific
reason, so there is no reason not to do it and lots of benefit to doing it.
llvm-svn: 276342
Previously LLVM_BUILD_GLOBAL_ISEL was a boolean variable and although,
this is strictly identical to an option, it did not convey the
information that the user may set it. Options are here for that.
llvm-svn: 276306
This option is the equivalent option to LLVM_BUILD_TOOLS but for executables
created via add_llvm_utility.
This is a useful tool for improving compile time in situations where LLVM is
used as a library and no testing tools are needed.
It follows the exact same implemention model as LLVM_BUILD_TOOLS.
Since the option is by default set to on, no behavior is changed unless one sets
it from the command line to be false.
llvm-svn: 275007
When compiling with modules, header A and B can be in the same module M.
B depends on intrinsics_gen and A doesn't. Compiling a source file #include-ing
header A, we implicitly request module M to be built. It puts header A and B in
the same TU and tries to build them. Since B depends on intrinsics_gen (which
might not be built yet) we run into build failures.
This should fix our modules buildbot.
Patch reviewed by Chris Bieneman.
llvm-svn: 274270
On Darwin it is currently impossible to build LLVM with modules
because the Darwin system module map is not compatible with
-fmodules-local-submodule-visibility at this point in time. This
patch makes the flag optional and off by default on Darwin so it
becomes possible to build LLVM with modules again.
http://reviews.llvm.org/D21827
rdar://problem/27019000
llvm-svn: 274196
Summary:
There are a few LLVM projects that produce runtime libraries. Ideally
runtime libraries should be built differently than other projects,
specifically they should be built using the just-built toolchain.
There is support for building compiler-rt in this way from the clang
build. Moving this logic into the LLVM build is interesting because it
provides a simpler way to extend the just-built toolchain to include
LLD and the LLVM object file tools.
Once this functionality is better fleshed out and tested we’ll want to
encapsulate it in a module that can be used for clang standalone
builds, and we’ll want to make it the default way to build compiler-rt.
With this patch applied there is no immediate change in the build.
Moving compiler-rt out from llvm/projects into llvm/runtimes enables
the functionality.
This code has a few improvements over the method provided by
LLVM_BUILD_EXTERNAL_COMPILER_RT. Specifically the sub-ninja command is
always invoked, so changes to compiler-rt source files will get built
properly, so this patch can be used for iterative development with
just-built tools.
This first patch only works with compiler-rt. Support for other
runtime projects will be coming in follow-up patches.
Reviewers: chandlerc, bogner
Subscribers: kubabrecka, llvm-commits
Differential Revision: http://reviews.llvm.org/D20992
llvm-svn: 273620
This patch adds a new option LLVM_TOOLS_INSTALL_DIR which allows customizing the location executables and symlinks get installed to. This adds the functionality provided by autoconf's --bindir flag.
This patch is based on patches from and collaboration with Tony Kelman, and replaces http://reviews.llvm.org/D20934.
llvm-svn: 272200
Summary:
As per the discussion on LLVM-dev this patch proposes removing LLVM_ENABLE_TIMESTAMPS.
The only complicated bit of this patch is the Windows support. On windows we used to log an error if /INCREMENTAL was passed to the linker when timestamps were disabled.
With this change since timestamps in code are always disabled we will always compile on windows with /Brepro unless /INCREMENTAL is specified, and we will log a warning when /INCREMENTAL is specified to notify the user that the build will be non-deterministic.
See: http://lists.llvm.org/pipermail/llvm-dev/2016-May/098990.html
Reviewers: bogner, silvas, rnk
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D19892
llvm-svn: 268670
This backend was supposed to generate C++ code which will re-construct
the LLVM IR passed as input. This seems to me to have very marginal
usefulness in the first place.
However, the code has never been updated to use IRBuilder, which makes
its current value negative -- people who look at the output may be
steered to use the *wrong* C++ APIs to construct IR.
Furthermore, it's generated code that doesn't compile since at least
2013.
Differential Revision: http://reviews.llvm.org/D19942
llvm-svn: 268631
Summary:
Before this change certain Polly variables have been used both as user-facing
CACHED cmake variables as well as uncached internal variables. Even though
this seems to have worked OK in practice, the behavior only worked due to
one variable shadowing the other. This behavior has been found confusing.
To make the use of cmake variables more clear we now prefix the cached, user
facing variables with LLVM_ as it is common habit for LLVM options and also
moved the _POLLY_ term to the beginning to ensure related options are sorted
after each other. The variables that control the behavior of LLVM/Polly are then
set by forwarding the values set in the user facing option variables.
As a result, Polly is now enabled with LLVM_POLLY_BUILD instead of BUILD_POLLY
and the linking behavior of Polly is controlled with LLVM_POLLY_LINK_INTO_TOOLS
instead of LINK_POLLY_INTO_TOOLS.
Reviewers: bogner, Meinersbur
Subscribers: pollydev, llvm-commits
Differential Revision: http://reviews.llvm.org/D19907
llvm-svn: 268537
Summary:
Historically, we had a switch in the Makefiles for turning on "expensive
checks". This has never been ported to the cmake build, but the
(dead-ish) code is still around.
This will also make it easier to turn it on in buildbots.
Reviewers: chandlerc
Subscribers: jyknight, mzolotukhin, RKSimon, gberry, llvm-commits
Differential Revision: http://reviews.llvm.org/D19723
llvm-svn: 268050
This is the second try. This time we disable this feature if no Polly checkout
is available. For this to work we need to check if tools/polly is present
early enough that our decision is known before cmake generates Config/config.h.
With Polly checked into LLVM it was since a long time possible to compile
clang/opt/bugpoint with Polly support directly linked in, instead of only
providing Polly as a separate loadable module. This commit switches the
default from providing Polly as a module to linking Polly into tools, such
that it becomes unnecessary to load the Polly module when playing with Polly.
Such configuration has shown a lot more convenient for day-to-day Polly use.
This change does not impact the default behavior of any tool, if Polly is not
explicitly enabled when calling clang/opt/bugpoint Polly does not affect
compilation.
This change also does not impact normal LLVM/clang checkouts that do not
contain Polly.
Reviewers: jdoerfert, Meinersbur
Subscribers: pollydev, llvm-commits
Differential Revision: http://reviews.llvm.org/D19711
llvm-svn: 268048
With Polly checked into LLVM it was since a long time possible to compile
clang/opt/bugpoint with Polly support directly linked in, instead of only
providing Polly as a separate loadable module. This commit switches the
default from providing Polly as a module to linking Polly into tools, such
that it becomes unnecessary to load the Polly module when playing with Polly.
Such configuration has shown a lot more convenient for day-to-day Polly use.
This change does not impact the default behavior of any tool, if Polly is not
explicitly enabled when calling clang/opt/bugpoint Polly does not affect
compilation.
This change also does not impact normal LLVM/clang checkouts that do not
contain Polly.
Reviewers: jdoerfert, Meinersbur, sebpop, etherzhhb, zinob, hiraditya
Subscribers: pollydev, llvm-commits
Differential Revision: http://reviews.llvm.org/D19711
llvm-svn: 268033
Summary: Using libtool instead of ar and ranlib on Darwin shaves a minute off my clang build. This is because on Darwin libtool is optimized to give hints to the kernel about filesystem interactions that allow it to be faster.
Reviewers: bogner, pete
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D19611
llvm-svn: 267930
If anybody is actually using this, it probably doesn't do what they
think it does. This actually causes the dylib to *export* a
__cxa_atexit symbol, so anything that links it probably loses their
exit time destructors as well as disabling LLVM's.
This just removes the option entirely. If somebody does need this
behaviour we should figure out a more principled way to do it.
This is effectively a revert of r223805.
llvm-svn: 263498
This allows a user to specify "Native" as a target when configuring LLVM. Native will resolve to the LLVM_NATIVE_ARCH, which is the target that supports code generation for the host.
llvm-svn: 262070
The idea here is to provide a customizable install target that only depends on building the things you actually want to install. It relies on each component being installed having an auto-generated install-${component}, which in turn depends only on the target being installed.
This is fundamentally a workaround for the fact that CMake generates build files which have their "install" target depend on the "all" target. This results in "ninja install" building a bunch of unneeded things.
llvm-svn: 261681
This patch adds the necessary plumbing to cmake to build the sources related to
GlobalISel.
To build the sources related to GlobalISel, we need to add -DBUILD_GLOBAL_ISEL=ON.
By default, this is OFF, thus GlobalISel sources will not impact people that do
not explicitly opt-in.
Differential Revision: http://reviews.llvm.org/D15983
llvm-svn: 258344
This reverts r257221.
This caused several build bot failures
* It looks like some of the tests don't work correctly under Windows
* It looks like the lit per test timeout tests fail
So I'm reverting for now. Once the above failures are fixed running
lit's tests can be enabled again.
llvm-svn: 257268
directy with ``make check-lit`` and are run as part of
``make check-all``.
In principle we should run lit's testsuite before testing LLVM using lit
so that any problems with lit get discovered before testing LLVM so we
can bail out early. However this implementation (``check-all`` runs all
tests together) seemed simpler and will still report failing lit tests.
Note that the tests and the configured ``lit.site.cfg`` have to be
copied into the build directory to avoid polluting the source tree.
llvm-svn: 257221
This generates a compile_commands.json file, which tells tools like
YouCompleteMe and clang_complete exactly how to build each source file.
Patch by Justin Lebar!
llvm-svn: 255789
Summary: This adds support for generating dSYM files and stripping debug info from executables and dylibs. It also supports passing -object_path_lto to the linker to generate dSYMs for LTO builds.
Reviewers: bogner, friss
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D15133
llvm-svn: 254627
Summary:
This patch adds a new CMake module for working with ExternalProjects. This wrapper for ExternalProject supports using just-built tools and can hook up dependencies properly so that projects get cleared out.
The example usage here is for the llvm test-suite. In this example, the test-suite is setup as dependent on clang and lld if they are in-tree. If the clang or lld binaries change the test-suite is re-configured, cleaned, and rebuilt.
This cleanup and abstraction wrapping ExternalProject can be extended and applied to other runtime libraries like compiler-rt and libcxx.
Reviewers: samsonov, jroelofs, rengolin, jmolloy
Subscribers: jmolloy, llvm-commits
Differential Revision: http://reviews.llvm.org/D14513
llvm-svn: 252747
Summary:
We've had a lot of discussion in the past about the meaningful and useful default behaviors for the llvm-shlib tool. The original implementation was heavily geared toward Apple's use, and I think that was wrong. This patch seeks to correct that.
I've removed the LLVM_DYLIB_EXPORT_ALL variable and made libLLVM export everything by default.
I've also added a new target that is only built on Darwin for libLLVM-C as a library that re-exports the LLVM-C API. This library is not built on Linux because ELF doesn't support re-export libraries in the same way MachO does.
Reviewers: chapuni, resistor, bogner, axw
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D13842
llvm-svn: 251411
This is because if you set one of the variables to 0, if(NOT ...) is true, which isn't what you actually want. Should have thought that through better the first time.
llvm-svn: 250841
CMake's set command overwrites existing values. Package maintainers may want or need to set the version variables manually, so we need to only set them if they are not already defined. Note I use the "if(NOT DEFINED ...)" syntax deliberately in the last case because empty string is a valid value for the suffx, but not the other variables.
llvm-svn: 250333
CMake 3.0 introduced the VERSION option for the project() command. If you don't specify the VERSION in the function it will clear out variables matching ${PROJECT_NAME}_VERSION_${MAJOR|MINOR|PATCH|TWEAK}.
This makes overriding LLVM_VERSION_* not work properly with newer versions of CMake. To make this work properly we need to:
(1) Optionally set the policy to NEW
(2) Move default versions and setting PACKAGE_VERSION to before the call to project()
(3) If the policy is set, pass the VERSION and LANGUAGES options in the new format
This change should have no behavioral change for CMake versions before 3.0, and it makes the behavior of later versions match the earlier versions.
llvm-svn: 250275
Eugene Zelenko