Currently, the Clang version is computed as follows:

 1. LLVM defines major, minor, and patch versions, all statically set. Today,
    these are 4, 0, and 0, respectively.
 2. The static version numbers are combined into PACKAGE_VERSION along with a
    suffix, so the result today looks like "4.0.0svn".
 3. Clang extracts CLANG_VERSION from PACKAGE_VERSION using a regexp. The regexp
    allows the patch level to omitted, and drops any non-digit trailing values.
    Today, this result looks like "4.0.0".
 4. CLANG_VERSION is then split further into CLANG_VERSION_MAJOR and
    CLANG_VERSION_MINOR. Today, these resolve to 4 and 0, respectively.
 5. If CLANG_VERSION matches a regexp with three version components, then
    CLANG_VERSION_PATCHLEVEL is extracted and the CLANG_HAS_VERSION_PATCHLEVEL
    variable is set to 1. Today, these values are 0 and 1, respectively.
 6. The CLANG_VERSION_* variables (and CLANG_HAS_VERSION_PATCHLEVEL) are
    configured into [llvm/tools/clang/]include/clang/Basic/Version.inc
    verbatim by CMake.
 7. In [llvm/tools/clang/]include/clang/Basic/Version.h, macros are defined
    conditionally, based on CLANG_HAS_VERSION_PATCHLEVEL, to compute
    CLANG_VERSION_STRING as either a two- or three-level version number. Today,
    this value is "4.0.0", because despite the patchlevel being 0, it was
    matched by regexp and is thus "HAS"ed by the preprocessor. This string is
    then used wherever Clang's "version" is needed [*].

[*] Including, notably, by compiler-rt, for computing its installation path.

This change collapses steps 2-5 by defaulting Clang to use LLVM's (non-string)
version components for the Clang version (see [*] for why not PACKAGE_VERSION),
and collapses steps 6 and 7 by simply writing CLANG_VERSION_STRING into
Version.inc. The Clang version today always uses the patchlevel form, so the
collapsed Version.inc does not have logic for a version without a patch level.

Historically speaking, this technique began with the VER file in r82085 (which
survives in the form of the regexp in #3). The major, minor, and patchlevel
versions were introduced by r106863 (which remains in #4-6). The VER file itself
was deleted in favor of the LLVM version number in r106914. On the LLVM side,
the individual LLVM_VERSION_MAJOR, LLVM_VERSION_MINOR, and PACKAGE_VERSION
weren't introduced for nearly two more years, until r150405.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@281666 91177308-0d34-0410-b5e6-96231b3b80d8

Summary:
Add a cmake check for sys/resource.h and replace the __has_include() check with its result, in order to make it possible to use rlimits when building with compilers not supporting __has_include() -- i.e. when bootstrapping.

// Please also re-apply dfcd52eb (llvm-config.h fix)

Patch by: Michał Górny

Reviewers: rsmith, beanz

Subscribers: cfe-commits

Differential Revision: https://reviews.llvm.org/D23744

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@279559 91177308-0d34-0410-b5e6-96231b3b80d8

This patch adds a few new convenience options used by the PGO CMake cache to setup options on bootstrap stages. The new options are:

PGO_INSTRUMENT_LTO - Builds the instrumented and final builds with LTO
PGO_BUILD_CONFIGURATION - Accepts a CMake cache script that can be used for complex configuration of the stage2-instrumented and stage2 builds.

The patch also includes a fix for bootstrap dependencies so that the instrumented LTO tools don't get used when building the final stage, and it adds distribution targets to the passthrough.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@278862 91177308-0d34-0410-b5e6-96231b3b80d8

This patch introduces a new cmake variable: CLANG_DEFAULT_RTLIB, thru
which we can specify a default value for -rtlib (libgcc or
compiler-rt) at build time, just like how we set the default C++
stdlib thru CLANG_DEFAULT_CXX_STDLIB.

With these two options, we can configure clang to build binaries on
Linux that have no runtime dependence on any gcc libs (libstdc++ or
libgcc_s).

Patch by Lei Zhang!

Differential Revision: https://reviews.llvm.org/D22663

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@276848 91177308-0d34-0410-b5e6-96231b3b80d8

On OS X 10.11 System Integrity Protection prevents the DYLD environment variables from being set on system binaries. To work around this r276710 accepts DYLD_LIBRARY_PATH as a CMake variable and sets it directly on the archiver commands.

To make this work with bootstrapping we need to set DYLD_LIBRARY_PATH to the current stage's library directory and pass that into the next stage's configuration.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@276711 91177308-0d34-0410-b5e6-96231b3b80d8

In Bootstrap builds Clang logs some warnings. These are caused because Clang passes CLANG_STAGE and BOOTSTRAP_DEFAULT_PASSTHROUGH into the next stage's configuration.

BOOTSTRAP_DEFAULT_PASSTHROUGH shouldn't be passed, so it is renamed to _BOOTSTRAP_DEFAULT_PASSTHROUGH, to prevent passthrough.

CLANG_STAGE should be passed, so I've changed the code to log it if it is set outside the if(CLANG_ENABLE_BOOTSTRAP) block. This makes the variable always used, so the warning goes away.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@276674 91177308-0d34-0410-b5e6-96231b3b80d8

We agreed to call it "platform default" instead of "architecture default".
(see D17286)

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@276618 91177308-0d34-0410-b5e6-96231b3b80d8

LLVM_BUILD_TOOLS is a boolean variable that controls whether or not generated
targets for llvm tools are built by the "all" target. CLANG_BUILD_TOOLS is an
analogous variable for clang targets.

This is useful functionality for selectively disabling the building of clang
targets by default to speed up builds.

In terms of implementation, I just followed the model of LLVM's implementation
of this functionality.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@275006 91177308-0d34-0410-b5e6-96231b3b80d8

This matches how LLVM has its cmake files organized and is cleaner than just
shoving this business logic into the main CMakeLists.txt.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@274992 91177308-0d34-0410-b5e6-96231b3b80d8

[cmake] Move creation of ClangTargets and installation of ClangConfig.cmake from ./CMakeLists.txt -> ./cmake/modules/CMakeLists.txt.

This matches LLVM.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@274157 91177308-0d34-0410-b5e6-96231b3b80d8

I added this option in r257827 to try and add compatibility with autoconf. At the time I misunderstood the problem.

Our CMake automatically generates the SVN revision information and generates a build action to update it so builds don't need to be re-configured on SCM update (which is a better solution than we had in autoconf).

The problem I was actually seeing was isolated cases where SVN revision information isn't available because the repository structures have been removed. This happens in some automated testing systems.

This patch allows SVN_REVISION to be overridden if the build configuration could not find the SCM repository structures, and removes the code from my original patch because it is unnecessary.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@273714 91177308-0d34-0410-b5e6-96231b3b80d8

This corresponds to binutils' --enable-x86-relax-relocations.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@273224 91177308-0d34-0410-b5e6-96231b3b80d8

Now that we're on CMake 3.4.3 all the ExternalProject features we use are supported everywhere, so we don't need the version checks anymore.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@272324 91177308-0d34-0410-b5e6-96231b3b80d8

We don't need any checks for this code anymore. Since CMake version is always greater than 3 we can always generate the exports file.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@272323 91177308-0d34-0410-b5e6-96231b3b80d8

CMake 2.8.12 introduced interface libraries and some related policies. This removes the conditional block because we're now past 2.8.12.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@272312 91177308-0d34-0410-b5e6-96231b3b80d8

This reverts r272275. This actually wasn't the right way to fix the problem. The correct solution is in r272279.

Applying the fix to LLVM as done in r272279, means this fix will get picked up by all projects building out of tree using LLVM's CMake modules. As opposed to the fix I had in r272275, which would require each project to change.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@272280 91177308-0d34-0410-b5e6-96231b3b80d8

The out-of-tree build needs to read LLVM_TOOLS_INSTALL_DIR out of TOOLS_BINARY_DIR because LLVM_TOOLS_INSTALL_DIR is used by AddLLVM.cmake

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@272275 91177308-0d34-0410-b5e6-96231b3b80d8

We now have a cmake option to change the default: ENABLE_LINKER_BUILD_ID.

The reason is that build-id is fairly expensive, so we shouldn't impose
it in the regular edit/build cycle.

This is similar to gcc, that has an off by default --enable-linker-build-id
option.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@271692 91177308-0d34-0410-b5e6-96231b3b80d8

Summary:
This is as per the discussions on developer lists:

http://lists.llvm.org/pipermail/llvm-dev/2016-April/098780.html
http://lists.llvm.org/pipermail/llvm-dev/2016-May/100058.html

Subscribers: cfe-commits

Differential Revision: http://reviews.llvm.org/D20823

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@271326 91177308-0d34-0410-b5e6-96231b3b80d8

llvm-ar isn't really supported for Darwin, instead the host tools will load libLTO, so we can use the just-built libLTO.

This actually makes Darwin bootstrap builds a little faster because you don't need to build llvm-ar before starting the next stage.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@267756 91177308-0d34-0410-b5e6-96231b3b80d8

This is re-landing r260742. I've reworked the conditionals so that it only hits when targeting Apple platforms with ld64.

Original Summary:
With this change generating clang order files using dtrace uses the following workflow:

cmake <whatever options you want>

ninja generate-order-file

ninja clang

This patch works by setting a default path to the order file (which can be overridden by the user). If the order file doesn't exist during configuration CMake will create an empty one.

CMake then ties up the dependencies between the clang link job and the order file, and generate-order-file overwrites CLANG_ORDER_FILE with the new order file.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@265864 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@264610 91177308-0d34-0410-b5e6-96231b3b80d8

Use VS2015 Project Support for Natvis to eliminate the need to manually install clang native visualizer

This is the clang equivalent to llvm commit 264601. When using Visual Studio 2015, cmake now puts the native visualizers in llvm.sln, so the developer automatically sees custom visualizations.
Much thanks to ariccio who provided extensive help on this change. (manual installation still needed on VS2013).



git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@264603 91177308-0d34-0410-b5e6-96231b3b80d8

LLVM r263566 adds a generic PACKAGE_VENDOR configuration which can be used to specify the vendor for LLVM toolchain tools. This change defaults the CLANG_VENDOR to the PACKAGE_VENDOR so that you don't have to specify both when building a package.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@263570 91177308-0d34-0410-b5e6-96231b3b80d8

This is needed to build the gold plugin in multi-stage builds.

Patch by Mike Edwards

Differential Revision: http://reviews.llvm.org/D17655

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@262065 91177308-0d34-0410-b5e6-96231b3b80d8

This appears to be passing '-Wl,-order_file' to Linux link commands,
which then causes the linker to silently, behind the scenes, write the
output to 'rder_file' instead of somewhere else. Will work with Chris to
figure out the proper support for this, but so far there are numerous
people who can't get Clang to update when they build because of this.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@261054 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@260744 91177308-0d34-0410-b5e6-96231b3b80d8

Summary:
This commit re-lands r259862. The underlying cause of the build breakage was an incorrectly written capabilities test. In tools/Driver/CMakeLists.txt I was attempting to check if a linker flag worked, the test was passing it to the compiler, not the linker. CMake doesn't have a linker test, so we have a hand-rolled one.

Original Patch Review: http://reviews.llvm.org/D16896

Original Summary:
With this change generating clang order files using dtrace uses the following workflow:

cmake <whatever options you want>

ninja generate-order-file

ninja clang

This patch works by setting a default path to the order file (which can be overridden by the user). If the order file doesn't exist during configuration CMake will create an empty one.

CMake then ties up the dependencies between the clang link job and the order file, and generate-order-file overwrites CLANG_ORDER_FILE with the new order file.

Reviewers: bogner

Subscribers: cfe-commits

Differential Revision: http://reviews.llvm.org/D16999

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@260742 91177308-0d34-0410-b5e6-96231b3b80d8

This was originally a hacky if(APPLE) block. Now that we have an option for enabling LTO, it is better to properly gate this.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@260707 91177308-0d34-0410-b5e6-96231b3b80d8

With this option one can optionally override the architecture dependent
default library to use if no -stdlib= is provided on compiler invocation.

Differential Revision: http://reviews.llvm.org/D15920

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@260662 91177308-0d34-0410-b5e6-96231b3b80d8

For multi-stage builds we need to pass any overridden source directory variables. Without passing these the subsequent stages won't find the project sources.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@260341 91177308-0d34-0410-b5e6-96231b3b80d8

Seriously... CMake... You're on my list...

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@259873 91177308-0d34-0410-b5e6-96231b3b80d8

This reverts commit r259862, and attempts to fix builder CMakeCaches.

Will try this again some other time...

Conflicts:

	CMakeLists.txt
	tools/driver/CMakeLists.txt

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@259872 91177308-0d34-0410-b5e6-96231b3b80d8

This change will catch any bots that generated the order file that GNU ld doesn't like and delete it before trying to generate one that I think GNU ld will deal with.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@259871 91177308-0d34-0410-b5e6-96231b3b80d8

I can't reproduce this locally, but I think this may fix it.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@259870 91177308-0d34-0410-b5e6-96231b3b80d8

Summary:
With this change generating clang order files using dtrace uses the following workflow:

cmake <whatever options you want>

ninja generate-order-file

ninja clang

This patch works by setting a default path to the order file (which can be overridden by the user). If the order file doesn't exist during configuration CMake will create an empty one.

CMake then ties up the dependencies between the clang link job and the order file, and generate-order-file overwrites CLANG_ORDER_FILE with the new order file.

Reviewers: bogner

Subscribers: cfe-commits

Differential Revision: http://reviews.llvm.org/D16896

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@259862 91177308-0d34-0410-b5e6-96231b3b80d8

This is the right location for platform-specific files.

Also, search for LLVM's CMake files in this directory.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@259822 91177308-0d34-0410-b5e6-96231b3b80d8

I can't apply export to tools without getting some strange CMake spew. The behavior here is a bit unexpected. CMake is complaining about static link dependencies not being in the same export set, which shouldn't matter.

In the short term it is easier to just remove the export set (which was just added in r258209) while I sort this out.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@258214 91177308-0d34-0410-b5e6-96231b3b80d8

[CMake] Creating add_clang_tool macro to wrap add_clang_executable and generate install actions and targets.

This change brings forward the LLVM convention that "executables" are just runnable binaries, and "tools" are executables that are part of the project's install.

Having this abstraction will allow us to simplify some of the tool CMakeLists files, and it will standardize some of the install behaviors.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@258209 91177308-0d34-0410-b5e6-96231b3b80d8

Only set -DSVN_REVISION if CLANG_APPEND_VC_REV=On

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@258143 91177308-0d34-0410-b5e6-96231b3b80d8