The Xcode and Visual Studio generators always log "-- No build type selected, default to Debug". This is because CMake doesn't initialize "CMAKE_CONFIGURATION_TYPES" until the generator's EnableLanguage call gets hit.
The first place EnableLanguage gets hit in our configuration is in the project() call. Since CMAKE_BUILD_TYPE isn't used until after we call project() it is safe to just move this check down a bit.
llvm-svn: 279110
This patch has the following changes
The CMake variable LLVM_CCACHE_BUILD is set to OFF by default.
Set this to ON for a ccache enabled build
CCACHE_CPP2 is required to compile the source file directly instead
of compiling the preprocessed file. This will help WERROR is turned ON
for a host clang compiler
The below two options makes more sense in the context of a buildbot
CCACHE_HASHDIR is required to maintain the separate cached data across
builders. This will also help the debuggers to point to the correct source
location
CCACHE_SIZE is important in the perspective of buildbot to increase the
limit on the amount of data to hold in cache for faster compilation
CCACHE_DIR is used to save the cached data to a specific directory.
llvm-svn: 277389
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
CMake.
The Go bindings tests in an unoptimized build take over 30 seconds for
me, making it the slowest test in 'check-llvm' by a factor of two.
I've only rigged this up fully to the CMake build. If someone is
interested in rigging it up to the autoconf build, they're welcome to do
so.
llvm-svn: 247243
Summary:
Cross-compilation uses recursive cmake invocations to build native host
tools. These recursive invocations only forward a fixed set of
variables/options, since the native environment is generally the default.
This change adds -DLLVM_TARGET_IS_CROSSCOMPILE_HOST=TRUE to the recursive
cmake invocations, so that cmake files can distinguish these recursive
invocations from top-level ones, which can explain why expected options
are unset.
LLILC will use this to avoid trying to generate its build rules in the
crosscompile native host target (where it is not needed), which would fail
if attempted because LLILC requires a cmake variable passed on the command
line, which is not forwarded in the recursive invocation.
Reviewers: rnk, beanz
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D12679
llvm-svn: 247151
Summary:
This diff attempts to address the concerns raised in
http://reviews.llvm.org/D12488.
We introduce a new USE_SHARED option to llvm_config,
which, if set, causes the target to be linked against
libLLVM.
add_llvm_utility now uniformly disables linking against
libLLVM. These utilities are not intended for distribution,
and this keeps the option handling more centralised.
llvm-shlib is now processes before any other "tools"
subdirectories, ensuring the libLLVM target is defined
before its dependents.
One main difference from what was requested: llvm_config
does not prune LLVM_DYLIB_COMPONENTS from the components
passed into explicit_llvm_config. This is because the "all"
component does something special, adding additional
libraries (namely libLTO). Adding the component libraries
after libLLVM should not be a problem, as symbols will be
resolved in libLLVM first.
Finally, I'm not really happy with the
DISABLE_LLVM_LINK_LLVM option, but I'm not sure of a
better way to get the following:
- link all tools and shared libraries to libLLVM if
LLVM_LINK_LLVM_DYLIB is set
- some way of explicitly *not* doing so for utilities
and libLLVM itself
Suggestions for improvement here are particularly welcome.
Reviewers: beanz
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D12590
llvm-svn: 246918
Summary:
Three closely related changes, to have a mode in which we link all
executables and shared libraries against libLLVM.
1. Add a new LLVM_LINK_LLVM_DYLIB cmake option, which, when ON, will link
executables and shared libraries against libLLVM. For this to work, it
is necessary to also set LLVM_BUILD_LLVM_DYLIB and LLVM_DYLIB_EXPORT_ALL.
It is not strictly necessary to set LLVM_DISABLE_LLVM_DYLIB_ATEXIT, but
we also default to OFF in this mode, or tools tend to misbehave (e.g.
stdout may not flush on exit when output is buffered.)
llvm-config and Tablegen do not use libLLVM, as they are dependencies of
libLLVM.
2. Modify llvm-go to take a new flag, "linkmode=component-libs|dylib".
Depending on which one is passed (default is component-libs), we link
with the individual libraries or libLLVM respectively. We pass in dylib
when LLVM_LINK_LLVM_DYLIB is ON.
3. Fix LLVM_DYLIB_EXPORT_ALL on Linux, and expand the symbols exported to
actually export all. Don't strip leading underscore from symbols on Linux,
and make sure we get all exported symbols and weak-with-default symbols
("W" in nm output). Without these changes, passes won't load because
the "Annotate..." symbols defined in lib/Support/Valigrind.cpp are not
found.
Testing:
- Ran default build ("ninja") with LLVM, clang, compiler-rt, llgo, lldb.
- Ran "check", "check-clang", "check-tsan", "check-libgo" targets. I've
never had much success with LLDB tests, and llgoi is currently broken
so check-llgo fails for an unrelated reason.
- Ran "lldb" to ensure it loads.
Reviewers: chandlerc, beanz, pcc, rnk
Subscribers: rnk, chapuni, sylvestre.ledru, llvm-commits
Differential Revision: http://reviews.llvm.org/D12488
llvm-svn: 246527
Only disable the progress bar when we're generating VS project files,
like we do for XCode. This makes lit use the simple, non-curses progress
bar that looks like this with:
Testing: 0 .. 10.. 20.. 30.. 40.. 50.. 60.. 70.. 80.. 90..
Testing Time: 5.87s
llvm-svn: 244674
Apparently if you make a typo in the argument to CMAKE_BUILD_TYPE,
cmake silently accepts this but doesn't apply any particular build
type to your build. This means you get a build that doesn't really
make any sense - it's sort of a debug build with asserts disabled.
Error out instead.
llvm-svn: 244406
This allows asm files and Cxx files to be compiled with different flags
rather than treating them identically. LLVM itself has no asm files
other than tests, but this setting is inherited by the compiler-rt
project (unless compiled standalone), which does have asm files.
Differential Revision: http://reviews.llvm.org/D10707
llvm-svn: 243419
Enabling Ninja Job Pools needs to be dependent on the CMAKE_MAKE_PROGRAM not the CMAKE_GENERATOR. There are generators (like "Sublime Text 2 - Ninja") that also generate ninja build files. Basing of the CMAKE_MAKE_PROGRAM is the best future-proof way to handle this.
llvm-svn: 239076
The current check never passes, because CMAKE_MAKE_PROGRAM, at least on Linux,
includes the full path to the "ninja" binary; this effectively disables
compile/link jobs pools.
Use CMAKE_GENERATOR STREQUAL "Ninja" as a more reliable check.
llvm-svn: 239069
Summary: I've gotten feedback from users on CMake 2.8 that the compile and link pool options were not working. This is expected so I'm adding a warning so we can report invalid configurations to users.
Reviewers: eugenis
Reviewed By: eugenis
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D10193
llvm-svn: 239044
Added a new boolean CMake flag, LLVM_INSTALL_UTILS. When set,
the 'install' target will include in the bin directory the
utils binaries - e.g. FileCheck. This mirrors the autoconfig
behavior.
Test Plan:
Locally verified that utils binaries are copied when flag is set,
and not copied when flag is not set.
Reviewers: jfb, dschuff, beanz
Reviewed By: beanz
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D8587
Patch by Mircea Trofin
llvm-svn: 233385
Summary:
This patch is an attempt at making `DenseMapIterator`s "fail-fast".
Fail-fast iterators that have been invalidated due to insertion into
the host `DenseMap` deterministically trip an assert (in debug mode)
on access, instead of non-deterministically hitting memory corruption
issues.
Enabling fail-fast iterators breaks the LLVM C++ ABI, so they are
predicated on `LLVM_ENABLE_ABI_BREAKING_CHECKS`.
`LLVM_ENABLE_ABI_BREAKING_CHECKS` by default flips with
`LLVM_ENABLE_ASSERTS`, but can be clamped to ON or OFF using the CMake /
autoconf build system.
Reviewers: chandlerc, dexonsmith, rnk, zturner
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D8351
llvm-svn: 233310
In r233009 we gained specific check-llvm-* build targets for invoking
specific parts of the test suite, but they were copying the
dependencies for check-all, rather than just listing the dependencies
for check-llvm.
This moves the creation of these targets next to the check-llvm
target, and uses that target's configuration rather than the check-all
config.
llvm-svn: 233174
Summary:
This change makes CMake scan for lit suites and generate a target for each lit test suite. The targets follow the format check-<project>-<suite path>.
For example:
check-llvm-unit - Runs the LLVM unit tests
check-llvm-codegen-arm - Runs the ARM codeine tests
Note: These targets are not generated during multi-configuration generators (i.e. Xcode and Visual Studio) because target clutter impacts UI usability.
* Also fixed a minor issue that Duncan pointed out to me I was passing the suite to lit twice
Reviewers: chandlerc
Subscribers: aemerson, llvm-commits
Differential Revision: http://reviews.llvm.org/D8380
llvm-svn: 233009
Summary:
This change makes CMake scan for lit suites and generate a target for each lit test suite. The targets follow the format check-<project>-<suite path>.
For example:
check-llvm-unit - Runs the LLVM unit tests
check-llvm-codegen-arm - Runs the ARM codeine tests
Note: These targets are not generated during multi-configuration generators (i.e. Xcode and Visual Studio) because target clutter impacts UI usability.
Reviewers: chandlerc
Subscribers: aemerson, llvm-commits
Differential Revision: http://reviews.llvm.org/D8380
llvm-svn: 232671
The MSVC linker won't produce a .lib file for an executable that doesn't
export anything, and LLVM doesn't maintain dllexport annotations or .def
files listing all C++ symbols. It also doesn't support exporting all
symbols, like binutils ld.
CMake 3.2 changed the Ninja generator to list both the .exe and .lib
files as outputs of executable build targets. Ninja would always re-link
executables with ENABLE_EXPORTS because the .lib output file was not
present, and therefore the target was out of date.
llvm-svn: 232662
Summary: This change leverages the cross-compiling functionality in the build system to build a release tablegen executable for use during the build.
Reviewers: resistor, rnk
Reviewed By: rnk
Subscribers: rnk, joker.eph, llvm-commits
Differential Revision: http://reviews.llvm.org/D7349
llvm-svn: 231842
libc++. This lets me almost self-host on Linux with libc++ and libc++abi
very simply.
Currently, MCJIT and OrcJIT are failing due to uncaught exceptions, and
the Go binding tests are failing to build due to not linking in the
correct C++ standard library.
llvm-svn: 231560
When you use generator expressions in a library sources list,
and then later access the SOURCES property, the OLD behavior
(CMake 3.0 and earlier) would not include these expressions in
the SOURCES property. The NEW behavior (starting in CMake 3.1)
is that they do include the generator expressions in the SOURCES
property.
Differential Revision: http://reviews.llvm.org/D7870
Reviewed By: Chris Bieneman
llvm-svn: 230396
This reverts commit r230062.
Debian stable (wheezy) ships still with cmake 2.8.9.
The commit broke my LLVM/Polly buildbot, to my knowledge our only Linux+cmake
buildbot.
llvm-svn: 230343
Summary: Turns out if you don't set CMAKE_BUILD_TYPE the default is an empty string. This results in some of the behaviors of debug builds, but not all of them. For example ENABLE_ASSERTIONS is false.
Reviewers: rnk
Reviewed By: rnk
Subscribers: chapuni, llvm-commits
Differential Revision: http://reviews.llvm.org/D7360
llvm-svn: 230041
Summary:
* add_llvm_tool and add_llvm_library now add install-${name} targets to install specific components
* added installhdrs target to install just the LLVM headers
* The above changes only apply for single-configuration generators (Ninja, Makefiles...), not for multi-configuration generators (Visual Studio, Xcode...)
Reviewers: pete
Reviewed By: pete
Subscribers: pete, llvm-commits
Differential Revision: http://reviews.llvm.org/D7619
llvm-svn: 229727
If we are building an 64bit installer on Windows we have to adjust the
Program Files path otherwise it uses the wrong Program Files (x86)
directory. Related CMake bug report
http://public.kitware.com/Bug/view.php?id=14211
Patch by Ismail Dönmez!
llvm-svn: 227999
*numerous* places where it was missing in the CMake build. The primary
change here is that the suffix is now actually used for all of the lib
directories in the LLVM project's CMake. The various subprojects still
need similar treatment.
This is the first of a series of commits to try to make LLVM's cmake
effective in a multilib Linux installation. I don't think many people
are seriously using this variable so I'm hoping the fallout will be
minimal. A somewhat unfortunate consequence of the nature of these
commits is that until I land all of them, they will in part make the
brokenness of our multilib support more apparant. At the end, things
should actually work.
llvm-svn: 224919
Summary:
This is desirable for WebKit and other clients of the llvm-shlib because C++ exit time destructors have a tendency to crash when invoked from multi-threaded applications.
Ideally this option will be temporary, because the ideal fix is to just not have exit time destructors.
Reviewers: chapuni, ributzka
Reviewed By: ributzka
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D6572
llvm-svn: 223805
This change makes use of the new "job pool" capability in cmake 3.0
with ninja generator to allow limiting the number of concurrent jobs
of a certain type.
llvm-svn: 222341
A shared library (unlike a .a), has its dependencies recorded in the library and
we can pass PRIVATE to target_link_libraries.
This patch then removes some bogus dependencies when using
BUILD_SHARED_LIBS=ON. For example, we go from
build lib/CodeGen/CMakeFiles/LLVMCodeGen.dir/AggressiveAntiDepBreaker.cpp.o:
CXX_COMPILER /home/espindola/llvm/llvm/lib/CodeGen/AggressiveAntiDepBreaker.cpp
|| include/llvm/IR/intrinsics_gen lib/libLLVMSupport.so
lib/libLLVMCore.so lib/libLLVMBitReader.so
lib/libLLVMTransformUtils.so lib/libLLVMInstCombine.so
lib/libLLVMScalarOpts.so lib/libLLVMipa.so lib/libLLVMAnalysis.so
lib/libLLVMMCParser.so lib/libLLVMMC.so lib/libLLVMObject.so
lib/libLLVMTarget.so lib/libLLVMProfileData.so
to
build lib/CodeGen/CMakeFiles/LLVMCodeGen.dir/AggressiveAntiDepBreaker.cpp.o:
CXX_COMPILER /home/espindola/llvm/llvm/lib/CodeGen/AggressiveAntiDepBreaker.cpp
|| include/llvm/IR/intrinsics_gen lib/libLLVMSupport.so
lib/libLLVMCore.so lib/libLLVMTransformUtils.so
lib/libLLVMScalarOpts.so lib/libLLVMAnalysis.so lib/libLLVMMC.so
lib/libLLVMTarget.so
In fact, build.ninja goes from 5231028 bytes to 4896759 bytes.
With this, old verisons of bfd ld (2.24 is OK, 2.23 warns) will print a bogus
warning when building with BUILD_SHARED_LIBS.
llvm-svn: 221530
Summary:
This patch adds a new CMake build setting LLVM_BUILD_LLVM_DYLIB, which defaults to OFF. When set to ON, this will generate a shared library containing most of LLVM. The contents of the shared library can be overriden by specifying LLVM_DYLIB_COMPONENTS. LLVM_DYLIB_COMPONENTS can be set to a semi-colon delimited list of any LLVM components that you llvm-config can resolve.
On Windows, unless you are using Cygwin, you must specify an explicit symbol export file using LLVM_EXPORTED_SYMBOL_FILE. On Cygwin and all unix-like platforms if you do not specify LLVM_EXPORTED_SYMBOL_FILE, an export file containing only the LLVM C API will be auto-generated from the list of LLVM components specified in LLVM_DYLIB_COMPONENTS.
Reviewers: rnk
Reviewed By: rnk
Subscribers: rnk, llvm-commits
Differential Revision: http://reviews.llvm.org/D5890
llvm-svn: 220490
The basic idea is similar to the existing cross compilation support. A directory must be configured to build host versions of tablegen tools and llvm-config. This directory can be user provided (and configured), or it can be created during the build. During a build the native build directory will be configured and built to supply the tablegen tools used during the build. A user could also explicitly provide the tablegen executables to run on the CMake command line.
llvm-svn: 217105
The option check was being performed after config.h/llvm-config.h substitution,
generating incorrect macro definitions.
Fixes PR19614.
llvm-svn: 210311
This commit starts with a "git mv ARM64 AArch64" and continues out
from there, renaming the C++ classes, intrinsics, and other
target-local objects for consistency.
"ARM64" test directories are also moved, and tests that began their
life in ARM64 use an arm64 triple, those from AArch64 use an aarch64
triple. Both should be equivalent though.
This finishes the AArch64 merge, and everyone should feel free to
continue committing as normal now.
llvm-svn: 209577
I'm doing this in two phases for a better "git blame" record. This
commit removes the previous AArch64 backend and redirects all
functionality to ARM64. It also deduplicates test-lines and removes
orphaned AArch64 tests.
The next step will be "git mv ARM64 AArch64" and rewire most of the
tests.
Hopefully LLVM is still functional, though it would be even better if
no-one ever had to care because the rename happens straight
afterwards.
llvm-svn: 209576
The option LLVM_ENABLE_SPHINX option enables the "docs-llvm-html",
"docs-llvm-man" targets but does not build them by default. The
following CMake options have been added that control what targets are
made available
SPHINX_OUTPUT_HTML
SPHINX_OUTPUT_MAN
If LLVM_BUILD_DOCS is enabled then the enabled docs-llvm-* targets will
be built by default and if ``make install`` is run then docs-llvm-html
and docs-llvm-man will be installed (tested on Linux only).
The add_sphinx_target function is in its own file so it can be included
by other projects that use Sphinx for their documentation.
Patch by Daniel Liew <daniel.liew@imperial.ac.uk>!
llvm-svn: 206655
This adds a second implementation of the AArch64 architecture to LLVM,
accessible in parallel via the "arm64" triple. The plan over the
coming weeks & months is to merge the two into a single backend,
during which time thorough code review should naturally occur.
Everything will be easier with the target in-tree though, hence this
commit.
llvm-svn: 205090
the first run of the polly buildbot failed, and then it started passing.
This is due to the fact that the buildbot re-builds in an existing directory,
and the first run does not have WITH_POLLY set when it enters tools/.
Thus, cmake ignores the tools/polly dir in the first run, and then because
it reuses the CMakeCache.txt of the previous run, it has the WITH_POLLY set
by the previous run, and so it passes the second time.
llvm-svn: 203615
The shared library generated by autoconf will now be called
libLLVM-$(VERSION_MAJOR).$(VERSION_MINOR).$(VERSION_PATCH)$(VERSION_SUFFIX).so
and a symlink named
libLLVM-$(VERSION_MAJOR).$(VERSION_MINOR)$(VERSION_SUFFIX).so will
also be created in the install directory.
llvm-svn: 202720
Now, please don't get too excited. I've just toggled the default to suss
out the last remaining bot problems. This does *not* mean we can all go
write lots of C++11 code yet. I at least want to let the dust settle
from the bots first.
llvm-svn: 202542
This centralizes the Makefile handling of -install_name and -rpath. It also
moves the cmake build to using @rpath. The reason being that libclang needs it,
and it works for everything else.
A followup patch will move clang to using this and then there will be a single
point to edit to support other systems.
llvm-svn: 202499
For now, use both keywords, INTERFACE and PRIVATE via the variable,
- ${cmake_2_8_12_INTERFACE}
- ${cmake_2_8_12_PRIVATE}
They could be cleaned up when we introduce 2.8.12.
llvm-svn: 202239
Commit 201921 overrides setting of CMAKE_INSTALL_RPATH via the
command line. Last time this happened we applied another patch
to only set CMAKE_INSTALL_RPATH if already defined (r197825).
This patch does the same thing again, but only for the UNIX
case - we leave APPLE alone as presumably the original committer
is happy with the non-overriding behaviour.
llvm-svn: 202085
This reverts commit r201921.
This should bring the polly bots back. I will try to build it locally to
understand how cmake was setting the rpath of LLVMPolly.so.
llvm-svn: 201934
This works by asking cmake to use the "install rpath", but setting that rpath
to be relative.
Thanks a lot to Brad King for the help with CMake!
llvm-svn: 201921
The CMake install(DIRECTORY) command documents that it sets permissions
on directories it is asked to install. Since the <prefix>/include
directory may not be exclusive to the LLVM installation, we should not
ask CMake to manage permissions of that directory for us. Instead, give
only our own include/llvm and include/llvm-c subdirectories to the
install(DIRECTORY) command.
Fixes PR4500. Patch by Brad King.
llvm-svn: 201075
r200744 moved this into cmake/config-ix.cmake, so that it would happen very
early in the build process. However, standalone builds of Clang and other
external projects never include this file (which is correct).
Now, -stdlib=libc++ and the LLVM_COMPILER_IS_GCC_COMPATIBLE option are
both set in a new include file, HandleLLVMStdlib, which is included by
both config-ix.cmake and HandleLLVMOptions.cmake. This preserves existing
behavior for projects relying on HandleLLVMOptions and still does the
right thing for builds of LLVM itself.
llvm-svn: 200811
If LLVM_ENABLE_LIBCXX is specified, we should append -stdlib=libc++ to build
flags as early as possible, in particular, before we check for header presence
(as -stdlib=libc++ modifies header lookup rules). Otherwise we can find a header
at configure time (w/o -stdlib=libc++) but fail to find it at build time
(with -stdlib=libc++). See PR18569 for more details.
llvm-svn: 200744
In LLVM build tree, they points corresponding INTDIR.
In Clang standalone tree, they points external dir (llvm-config's --bindir and --libdir).
llvm-svn: 199595
option with the others in the top level CMakeLists, and put the check in
HandleLLVMOptions. This will also let it be used from the standalone
Clang builds.
llvm-svn: 199149
compiler version checking doesn't work on 2.8.7. This feature was
documented in 2.8.10, but existed for an unknown amount of time before
that.
I'm actually happy to revert this and remove the use of the feature if
there is anyone with a specific problem updating CMake. Please just let
me know. I don't want to re-implement this CMake functionality unless
there is a reason, and this is the only real way to find that out.
llvm-svn: 199148
It was too late to set BUG_REPORT_URL after configure_file(config.h).
BUG_REPORT_URL in config.h.cmake would be updated at 2nd run of cmake.
It caused many recompilations.
FYI, configure handles BUG_REPORT_URL in llvm side.
llvm-svn: 199076
Summary:
This parameter is required to build C++11 projects (like lld or lldb) on OS X as the default STL does not provide c++ classes.
CC: llvm-commits, triton
Differential Revision: http://llvm-reviews.chandlerc.com/D2381
llvm-svn: 198625
We have been seeing nasty directory layout with CMake multiconfig, such as,
bin/Release/clang.exe
lib/clang/3.x/...
lib/Release/clang/3.x/.. (duplicated)
Move the layout similar to autoconf's;
Release/bin/clang.exe
Release/lib/clang/3.x/...
Checked on Visual Studio 10. Could you guys please confirm my change on XCode(and other multiconfig builders)?
Note: Don't set variables CMAKE_*_OUTPUT_DIRECTORY any more, or a certain builder, for eaxample, msbuild.exe, would be confused.
llvm-svn: 198205
In some case, it may be required to build LLVM in C++11 mode, as some the subprojects (like lldb) requires it.
This mimics the autoconf behaviour.
However, given the discussions on the switch to C++11 of the codebase, this behaviour should evolve to default to C++11 with some checks of the compiler capabilities.
llvm-svn: 195727
- Allow overriding PACKAGE_VERSION from the command-line
- Use PACKAGE_VERSION to set CPACK_PACKAGE_VERSION (used by the Win installer)
- Don't include the version number in the CPack install dir or registry key.
Differential revision: http://llvm-reviews.chandlerc.com/D2245
llvm-svn: 195379
for release builds.
This is a follow-up to r194589. Aaron pointed out that building
libraries with /MT and using them in an application that uses a
different run-time library can be a bad idea.
Move the option to build with /MT behind a CMake option so it can be
turned on selectively, such as when building the toolchain installer.
llvm-svn: 194596
After r192904, Reid pointed out he thought we already set the stack
size for MSVC. Turns out we did, but it didn't seem to work.
This commit sets the stack size in a single place, using
CMAKE_EXE_LINKER_FLAGS because that seems to be the way that works
best.
llvm-svn: 192912
infrastructure.
This was essentially work toward PGO based on a design that had several
flaws, partially dating from a time when LLVM had a different
architecture, and with an effort to modernize it abandoned without being
completed. Since then, it has bitrotted for several years further. The
result is nearly unusable, and isn't helping any of the modern PGO
efforts. Instead, it is getting in the way, adding confusion about PGO
in LLVM and distracting everyone with maintenance on essentially dead
code. Removing it paves the way for modern efforts around PGO.
Among other effects, this removes the last of the runtime libraries from
LLVM. Those are being developed in the separate 'compiler-rt' project
now, with somewhat different licensing specifically more approriate for
runtimes.
llvm-svn: 191835
This makes sure we get the same behavior with all supported cmake versions. Once
we support only versions >= 2.8.11 we can experiment with other values or just
setting it for some binaries.
Patch by Greg Bedwell.
llvm-svn: 191372
- We do some nasty things w.r.t. installing or overriding signal handlers in
order to improve our crash recovery support or interaction with crash
reporting software, and those things are not necessarily appropriate when
LLVM is being linked into a client application that has its own ideas about
how to do things. This gives those clients a way to disable that handling at
build time.
- Currently, the code this guards is all Apple specific, but other platforms
might have the same concerns so I went for a more generic configure
name. Someone who is more familiar with library embedding on Windows can
handle choosing which of the Windows/Signals.inc behaviors might make sense
to go under this flag.
- This also fixes the proper autoconf'ing of ENABLE_BACKTRACES. The code
expects it to be undefined when disabled, but the autoconf check was just
defining it to 0.
llvm-svn: 189694
This adds the msbuild integration files to the install, provides batch scripts
for (un)installing it in a convenient way, and hooks up the nsis installer to
run those scripts.
Differential Revision: http://llvm-reviews.chandlerc.com/D1537
llvm-svn: 189434
This tweaks the CMake rules for building an installation package on Windows:
- Sets license file (otherwise nsis shows an ugly default)
- Adds LLVM logo
- Shows "do you want to add this to the system path" dialog.
Differential Revision: http://llvm-reviews.chandlerc.com/D1414
llvm-svn: 188509
We were marking both LLVMBUILDOUTPUT and LLVMBUILDERRORS as
ERROR_VARIABLES when clearly LLVMBUILDOUTPUT should be marked as
OUTPUT_VARIABLE.
llvm-svn: 188444
library for color support detection. This still will use a curses
library if that is all we have available on the system. This change
tries to use a smaller subset of the curses library, specifically the
subset that is on some systems split off into a separate library. For
example, if you install ncurses configured --with-tinfo, a 'libtinfo' is
install that provides just the terminfo querying functionality. That
library is now used instead of curses when it is available.
This happens to fix a build error on systems with that library because
when we tried to link ncurses into the binary, we didn't pull tinfo in
as well. =]
It should also provide an easy path for supporting the NetBSD
libterminfo library, but as I don't have access to a NetBSD system I'm
leaving adding that support to those folks.
llvm-svn: 188160
using it to detect whether or not a terminal supports colors. This
replaces a particularly egregious hack that merely compared the TERM
environment variable to "dumb". That doesn't really translate to
a reasonable experience for users that have actually ensured their
terminal's capabilities are accurately reflected.
This makes testing a terminal for color support somewhat more expensive,
but it is called very rarely anyways. The important fast path when the
output is being piped somewhere is already in place.
The global lock may seem excessive, but the spec for calling into curses
is *terrible*. The whole library is terrible, and I spent quite a bit of
time looking for a better way of doing this before convincing myself
that this was the fundamentally correct way to behave. The damage of the
curses library is very narrowly confined, and we continue to use raw
escape codes for actually manipulating the colors which is a much sane
system than directly using curses here (IMO).
If this causes trouble for folks, please let me know. I've tested it on
Linux and will watch the bots carefully. I've also worked to account for
the variances of curses interfaces that I could finde documentation for,
but that may not have been sufficient.
llvm-svn: 187874
The issue is that CMAKE_BUILD_TYPE=RelWithDebInfo LLVM_ENABLE_ASSERTIONS=ON was
not building with assertions enabled. (I was unable to find what in the LLVM
source tree was adding -DNDEBUG to the build line in this case, so decided that
it must be cmake itself that was adding it - this may depend on the cmake
version). The fix treats any mode that is not Debug as being the same as
Release for this purpose (previously it was being assumed that cmake would only
add -DNDEBUG for Release and not for RelWithDebInfo or MinSizeRel). If other
versions of cmake don't add -DNDEBUG for RelWithDebInfo then that's OK: with
this change you just get a useless but harmless -UNDEBUG or -DNDEBUG.
llvm-svn: 186499
