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

On fedora the ninja executable is called ninja-build :-(

llvm-svn: 252062

[CMake] Get rid of LLVM_DYLIB_EXPORT_ALL, and make it the default, add libLLVM-C on darwin to cover the C API needs.

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

I meant to put the POLICY setting below the version defaults.

llvm-svn: 250276

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] LLVM_PROFDATA_FILE only works if you're using clang, so we should error out if it is specified when not using clang.

Also updated the CMake docs.

Based on post-commit review of r250108 from Sean Silvas.

llvm-svn: 250150

Adds LLVM_PROFDATA_FILE option to allow specifying a profile data file to be used during compilation of LLVM and subprojects.

llvm-svn: 250108

This is a follow-on to r247308.

llvm-svn: 247443

llvm-svn: 247308

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

NFC

llvm-svn: 244659

This re-applies r244516 (effectively reverting r244516) without losing
the check that caused failures for VS.

llvm-svn: 244643

http://bb.pgr.jp/builders/msbuild-llvmclang-x64-msc18-DA/builds/475

llvm-svn: 244589

Juergen pointed out that this variable is treated in a case
insensitive way.

llvm-svn: 244516

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

Fixes build break reported in PR24358.

Patch by John Marino.

llvm-svn: 244232

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

llvm-svn: 242222

Patch by Xan López.

llvm-svn: 240308

llvm-svn: 239657

only cmake build change. autoconf build and docs will follow

email thread:
http://lists.cs.uiuc.edu/pipermail/llvmdev/2015-June/thread.html#86523

llvm-svn: 239410

This reverts commit r239035

llvm-svn: 239159

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

[CMake] Add warning for using compile and link pools on unsupported versions of CMake or non-ninja generators.

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

llvm-svn: 239035

Reviewed by Hans Wennborg

llvm-svn: 237372

[CMake] Updates to llvm-shlib to support overriding exports list and added an option to export all symbols.

llvm-svn: 234798

llvm-svn: 234343

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

This commit is in reference to the llvm-dev thread: http://lists.cs.uiuc.edu/pipermail/llvmdev/2015-March/083672.html

llvm-svn: 233008