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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@257268 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@257221 91177308-0d34-0410-b5e6-96231b3b80d8
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!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@255789 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@254627 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@252747 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@251411 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@250841 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@250333 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@250275 91177308-0d34-0410-b5e6-96231b3b80d8
Adds LLVM_PROFDATA_FILE option to allow specifying a profile data file to be used during compilation of LLVM and subprojects.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@250108 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@247243 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@247151 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@246918 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@246527 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@244674 91177308-0d34-0410-b5e6-96231b3b80d8
This re-applies r244516 (effectively reverting r244516) without losing
the check that caused failures for VS.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@244643 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@244406 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@243419 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@239076 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@239069 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@239044 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@233385 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@233310 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@233174 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@233009 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@232671 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@232662 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@231842 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@231560 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230396 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230343 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230041 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@229727 91177308-0d34-0410-b5e6-96231b3b80d8
This is based on the discussions on: [LLVMdev] [RFC] Raising LLVM minimum required MSVC version to 2013 for trunk
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@229320 91177308-0d34-0410-b5e6-96231b3b80d8
This is based on the discussions on: [LLVMdev] [RFC] Raising LLVM minimum required MSVC version to 2013 for trunk
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@229185 91177308-0d34-0410-b5e6-96231b3b80d8
*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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@224919 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223805 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@222341 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221530 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220490 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@217105 91177308-0d34-0410-b5e6-96231b3b80d8
The option check was being performed after config.h/llvm-config.h substitution,
generating incorrect macro definitions.
Fixes PR19614.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210311 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@209577 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@209576 91177308-0d34-0410-b5e6-96231b3b80d8
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>!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206655 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@205090 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@203615 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202720 91177308-0d34-0410-b5e6-96231b3b80d8
LLVM_ENABLE_CXX1Y (default *off*). =D C++98 is dead. Long live C++11.
I don't exactly recommend using C++1y just yet though...
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202567 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202542 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202499 91177308-0d34-0410-b5e6-96231b3b80d8
Using @executable_path/../lib matches what we have on Makefiles and works
with older versions of OS X too.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202302 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202239 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202085 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201934 91177308-0d34-0410-b5e6-96231b3b80d8
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!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201921 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201075 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200811 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200744 91177308-0d34-0410-b5e6-96231b3b80d8
In LLVM build tree, they points corresponding INTDIR.
In Clang standalone tree, they points external dir (llvm-config's --bindir and --libdir).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199595 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199149 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199148 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199076 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@198205 91177308-0d34-0410-b5e6-96231b3b80d8
Each of them forms like;
${CMAKE_BINARY_DIR}/bin/${CMAKE_CFG_INTDIR}
${CMAKE_BINARY_DIR}/lib/${CMAKE_CFG_INTDIR}
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197394 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195727 91177308-0d34-0410-b5e6-96231b3b80d8
- 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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195379 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194596 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@192912 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@191835 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@191372 91177308-0d34-0410-b5e6-96231b3b80d8
- 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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189694 91177308-0d34-0410-b5e6-96231b3b80d8
Requires shuffling the CPack code up before add_subdirectory(tools), but
that's where the version settings are anyway.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189615 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188509 91177308-0d34-0410-b5e6-96231b3b80d8
We were marking both LLVMBUILDOUTPUT and LLVMBUILDERRORS as
ERROR_VARIABLES when clearly LLVMBUILDOUTPUT should be marked as
OUTPUT_VARIABLE.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188444 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188160 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187874 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@186499 91177308-0d34-0410-b5e6-96231b3b80d8
