This gets rid of almost LLVM targets unconditionally depending on intrinsic_gen.
Clang's modules still have weird dependencies and hard to remove intrinsics_gen in better way.
Then, it'd be better to give whole clang targets depend on intrinsic_gen.
llvm-svn: 308844
LLVM_ENABLE_MODULES is sensitive of -D. Move them into config.h.
FIXME: It'd be better that they are #cmakedefine01 rather than #cmakedefine.
(#if FOO rather than #if defined(FOO))
Then we can find missing #include "clang/Config/config.h" in the future.
Differential Revision: https://reviews.llvm.org/D35527
llvm-svn: 308277
Summary:
This is a first patch for GSoC project, bash-completion for clang.
To use this on bash, please run `source clang/utils/bash-autocomplete.sh`.
bash-autocomplete.sh is code for bash-completion.
Simple flag completion and path completion is available in this patch.
Reviewers: teemperor, v.g.vassilev, ruiu, Bigcheese, efriedma
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D33237
llvm-svn: 303670
CMake handles paths with slashes. It caused cmake/install failure on msbuild.exe.
Note, Other llvm-config-oriented variables have been normalized since they are stored in the cache attributed with PATH.
llvm-svn: 294954
Use the new llvm_canonicalize_cmake_booleans() function to canonicalize
booleans for lit tests. Replace the duplicate ENABLE_CLANG* variables
used to hold canonicalized values with in-place canonicalization. Use
implicit logic in Python code to avoid overrelying on exact 0/1 values.
Differential Revision: https://reviews.llvm.org/D28529
llvm-svn: 293052
These two are independent: it's possible to use LLD without LTO,
and it's possible to do LTO build without LLD.
Differential Revision: https://reviews.llvm.org/D28821
llvm-svn: 292343
Use the new --cmakedir option to obtain LLVM_CMAKE_PATH straight from
llvm-config instead of reconstructing it locally.
Differential Revision: https://reviews.llvm.org/D26900
llvm-svn: 291495
This diff fixes the clean build of the target generate-order-file.
In llvm/tools/clang/CMakeLists.txt
add_subdirectory(utils/perf-training) should go after the block where
the value of the variable CLANG_ORDER_FILE is set - otherwise
(tested with cmake's version 3.6.2) the arguments of perf-helper.py gen-order-file
will be ill-formed (CLANG_ORDER_FILE will be empty).
Differential revision: https://reviews.llvm.org/D28153
llvm-svn: 290781
This change allows setting the default linker used by the Clang
driver when configuring the build.
Differential Revision: https://reviews.llvm.org/D25263
llvm-svn: 289668
lld has LTO support, if requested we should add a dependency on lld
rather than LLVMgold when doing LTO bootstrap build.
Differential Revision: https://reviews.llvm.org/D26649
llvm-svn: 287179
Having this target allows other parts of the build system to add to the bootstrap dependencies without needing to be defined before the bootstrap targets are created.
This will specifically be used connect the builtins build from the LLVM runtimes directory as a dependency of the next build stage.
llvm-svn: 284648
Update the lit search logic to support all names supported in LLVM
(since r283029). The search order (i.e. PATHS vs HINTS) does no really
matter since the established path is not used, except for determining
whether lit is available.
Differential Revision: https://reviews.llvm.org/D23745
llvm-svn: 284496
Checking if they evaluate to true cases prevents passing values that evaluate to false cases. Instead we should check if the variables are defined.
llvm-svn: 282122
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.
llvm-svn: 281666
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 dfcd52eb1d8e5d322404b40414cb7331c7380a8c (llvm-config.h fix)
Patch by: Michał Górny
Reviewers: rsmith, beanz
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D23744
llvm-svn: 279559
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.
llvm-svn: 278862
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
llvm-svn: 276848
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.
llvm-svn: 276711
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.
llvm-svn: 276674
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.
llvm-svn: 275006
This matches how LLVM has its cmake files organized and is cleaner than just
shoving this business logic into the main CMakeLists.txt.
llvm-svn: 274992
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.
llvm-svn: 273714
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.
llvm-svn: 272324
CMake 2.8.12 introduced interface libraries and some related policies. This removes the conditional block because we're now past 2.8.12.
llvm-svn: 272312
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.
llvm-svn: 272280
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
llvm-svn: 272275
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.
llvm-svn: 271692
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.
llvm-svn: 267756
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.
llvm-svn: 265864
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).
llvm-svn: 264603
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.
llvm-svn: 263570
This is needed to build the gold plugin in multi-stage builds.
Patch by Mike Edwards
Differential Revision: http://reviews.llvm.org/D17655
llvm-svn: 262065
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.
llvm-svn: 261054
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
llvm-svn: 260742
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
llvm-svn: 260662
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.
llvm-svn: 260341
This reverts commit r259862, and attempts to fix builder CMakeCaches.
Will try this again some other time...
Conflicts:
CMakeLists.txt
tools/driver/CMakeLists.txt
llvm-svn: 259872
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.
llvm-svn: 259871
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
llvm-svn: 259862
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.
llvm-svn: 258214
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.
llvm-svn: 258209
Summary:
This patch adds support for the clang multi-stage bootstrapping to support PGO profdata generation, and can build a 2 or 3 stage compiler.
With this patch applied you can configure your build directory with the following invocation of CMake:
cmake -G <generator> -C <path_to_clang>/cmake/caches/PGO.cmake <source dir>
After configuration the following additional targets will be generated:
stage2-instrumented:
Builds a stage1 x86 compiler, runtime, and required tools (llvm-config, llvm-profdata) then uses that compiler to build an instrumented stage2 compiler.
stage2-instrumented-generate-profdata:
Depends on "stage2-instrumented" and will use the instrumented compiler to generate profdata based on the training files in <clang>/utils/perf-training
stage2:
Depends on "stage2-instrumented-generate-profdata" and will use the stage1 compiler with the stage2 profdata to build a PGO-optimized compiler.
stage2-check-llvm:
Depends on stage2 and runs check-llvm using the stage3 compiler.
stage2-check-clang:
Depends on stage2 and runs check-clang using the stage3 compiler.
stage2-check-all:
Depends on stage2 and runs check-all using the stage3 compiler.
stage2-test-suite:
Depends on stage2 and runs the test-suite using the stage3 compiler (requires in-tree test-suite).
Reviewers: bogner, silvas, chandlerc
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D15584
llvm-svn: 256873
Summary:
This patch adds support for the clang multi-stage bootstrapping to support PGO profdata generation, and can build a 2 or 3 stage compiler.
With this patch applied you can configure your build directory with the following invocation of CMake:
cmake -G <generator> -C <path_to_clang>/cmake/caches/PGO.cmake <source dir>
After configuration the following additional targets will be generated:
stage2-instrumented:
Builds a stage1 x86 compiler, runtime, and required tools (llvm-config, llvm-profdata) then uses that compiler to build an instrumented stage2 compiler.
stage2-instrumented-generate-profdata:
Depends on "stage2-instrumented" and will use the instrumented compiler to generate profdata based on the training files in <clang>/utils/perf-training
stage2:
Depends on "stage2-instrumented-generate-profdata" and will use the stage1 compiler with the stage2 profdata to build a PGO-optimized compiler.
stage2-check-llvm:
Depends on stage2 and runs check-llvm using the stage3 compiler.
stage2-check-clang:
Depends on stage2 and runs check-clang using the stage3 compiler.
stage2-check-all:
Depends on stage2 and runs check-all using the stage3 compiler.
stage2-test-suite:
Depends on stage2 and runs the test-suite using the stage3 compiler (requires in-tree test-suite).
Reviewers: bogner, silvas, chandlerc
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D15584
llvm-svn: 256069
When you start chaining bootstrap stages the CMake-generated targets get unwieldy. This change supports naming the bootstrap targets and creating wrapper targets in the top-level build file.
Without this patch the default target generated for a second stage build was "bootstrap" with it the target is "stage2".
Also with some CMake goop setting CLANG_BOOTSTRAP_TARGETS, you can expose third stage targets as "stage3" instead of "bootstrap-bootstrap"
llvm-svn: 255813
Summary:
This patch adds support for using LIT to drive generating PGO profile data for clang.
This first pass implementation should work on Linux and Unix based platforms. If you build clang using CMake with LLVM_BUILD_INSTRUMENTED=On the CMake build generates a generate-profdata target that will use the just-built clang to build any test files (see hello_world.cpp as an example). Each test compile will generate profraw files for each clang process. After all tests have run CMake will merge the profraw files using llvm-profdata.
Future opportunities for extension:
* Support for Build->Profile->Build bootstrapping
* Support for linker order file generation using a similar mechanism and the same training data
* Support for Windows
Reviewers: dexonsmith, friss, bogner, cmatthews, vsk, silvas
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D15462
llvm-svn: 255740
Patch turns on OpenMP support in clang by default after fixing OpenMP buildbots.
Differential Revision: http://reviews.llvm.org/D13803
llvm-svn: 255223
This adds support for three types of argument specifications for bootstrap builds:
(1) Arguments prefixed with BOOTSTRAP_* will be passed through with the leading BOOTSTRAP_ removed.
(2) CLANG_BOOTSTRAP_PASSTHROUGH can specify a list of variables to be passed through as they are set.
(3) BOOTSTRAP_DEFAULT_PASSTHROUGH is a list of some default passthrough variables that are always passed through. Those variables include the version string and should only specify variables that are always expected to be the same between the stage1 and stage2
llvm-svn: 253721
Currently, cmake config files are only generated and installed when CLANG_BUILD_STANDALONE set, which means config file will not be generated or installed when clang is built with llvm. This change removes that restriction.
Thanks to Don Hinton <hintonda@gmail.com>
http://reviews.llvm.org/D13453
llvm-svn: 249935
Generation of clang symlinks now uses add_clang_symlink macro which uses add_llvm_symlink. Also the list of symlinks to generate is configurable via CLANG_LINKS_TO_CREATE.
This re-lands r248015, with fixes for clang symlinks to always be generated as part of the clang and install-clang targets.
llvm-svn: 248043
Generation of clang symlinks now uses add_clang_symlink macro which uses add_llvm_symlink. Also the list of symlinks to generate is configurable via CLANG_LINKS_TO_CREATE.
llvm-svn: 248015
When building with LTO the bootstrap builds need to depend on libLTO, llvm-ar, and llvm-ranlib, which all need to be passed into the bootstrap build. This functionality only works on Darwin.
llvm-svn: 247467
Summary: The code comments in the Makefile indicate this was put in place to support issues when building clang with GCC. Today clang's strict aliasing works, so we shouldn't pass -fno-strict-aliasing when building with clang.
Reviewers: bogner, echristo
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D12036
llvm-svn: 245304
Summary:
This patch adds a new CLANG_ENABLE_BOOTSTRAP option to CMake which adds targets for building a stage2 bootstrap compiler. The targets are:
bootstrap-configure
bootstrap-build
bootstrap (same as bootstrap-configure and bootstrap-build)
bootstrap-install
bootstrap-check-llvm
bootstrap-check-clang
bootstrap-check-all
If you are using 3.3.20150708 or greater it utilizes the ninja USES_TERMINAL_* settings on the external project so that the output is properly buffered.
Reviewers: bogner, chandlerc
Subscribers: filcab, cfe-commits
Differential Revision: http://reviews.llvm.org/D11743
llvm-svn: 244070
When setting the VERSIONINFO resource to embed version information into exe and
DLL files on Windows, override the default LLVM version number values with their
clang equivalents.
llvm-svn: 239617
Summary: This patch moves all the clang library targets into a ClangTargets export list, and installs it using the CMake install(EXPORT...) command.
Reviewers: rnk
Reviewed By: rnk
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D7623
llvm-svn: 238593
This isn't an actual revert of r237769, it just restores the behavior of
the Clang driver prior to it while completely re-implementing how that
behavior works.
This also re-does the work of making the default OpenMP runtime
selectable at CMake (or configure) time to work in the way all of our
other such hooks do (config.h, configure and cmake hooks, etc.).
I've re-implemented how we manage the '-fopenmp' flagset in an important
way. Now, the "default" hook just makes '-fopenmp' equivalent to
'-fopenmp=<default>' rather than a separate special beast. Also, there
is an '-fno-openmp' flag which does the obvious thing. Also, the code is
shared between all the places to select a known OpenMP runtime and act
on it.
Finally, and most significantly, I've taught the driver to inspect the
selected runtime when choosing whether to propagate the '-fopenmp' flag
to the frontend in the CC1 commandline. Without this, it isn't possible
to use Clang with libgomp, even if you were happy with the serial,
boring way in which it worked previously (ignoring all #pragmas but
linking in the library to satisfy direct calls into the runtime).
While I'm here, I've gone ahead and sketched out a path for the future
name of LLVM's OpenMP runtime (libomp) and the legacy support for its
current name (libiomp5) in what seems a more reasonable way.
To re-enable LLVM's OpenMP runtime (which I think should wait until the
normal getting started instructions are a reasonable way for falks to
check out, build, and install Clang with the runtime) all that needs to
change is the default string in the CMakeLists.txt and configure.ac
file. No code changes necessary.
I also added a test for the driver's behavior around OpenMP since it was
*completely missing* previously. Makes it unsurprising that we got it
wrong.
llvm-svn: 238389
a CLANG_LIBDIR_SUFFIX down from the build system and using that as part
of the default resource dir computation.
Without this, essentially nothing that uses the clang driver works when
building clang with a libdir suffix. This is probably the single biggest
missing piece of support for multilib as without this people could hack
clang to end up installed in the correct location, but it would then
fail to find its own basic resources. I know of at least one distro that
has some variation on this patch to hack around this; hopefully they'll
be able to use the libdir suffix functionality directly as the rest of
these bits land.
This required fixing a copy of the code to compute Clang's resource
directory that is buried inside of the frontend (!!!). It had bitrotted
significantly relative to the driver code. I've made it essentially
a clone of the driver code in order to keep tests (which use cc1
heavily) passing. This copy should probably just be removed and the
frontend taught to always rely on an explicit resource directory from
the driver, but that is a much more invasive change for another day.
I've also updated one test which actually encoded the resource directory
in its checked output to tolerate multilib suffixes.
Note that this relies on a prior LLVM commit to add a stub to the
autoconf build system for this variable.
llvm-svn: 224924
'lib' directories in the build. This variable is available now both as
part of the normal LLVM build an as part of a standalone build as I've
added it to the LLVMConfig.cmake output.
With this change we should at least put libraries into the multilib
directory correctly. It is the first step in getting Clang to be
reasonably multilib aware.
llvm-svn: 224923
The regex should not accept an empty version number.
The previous attempt at r223106 failed, and the build was still erroring:
CMake Error at tools/clang/CMakeLists.txt:269 (string):
string sub-command REGEX, mode REPLACE regex "[^0-9]*([0-9.]*).*" matched
an empty string.
llvm-svn: 223333
If the output of 'ld -v' didn't match the regexes, CMake would previously error
with a message like:
CMake Error at tools/clang/CMakeLists.txt:269 (string):
string sub-command REGEX, mode REPLACE regex "[^0-9]*([0-9.]*).*" matched
an empty string.
llvm-svn: 223106
The Autoconf build already does this, but it was never ported to
CMake. The host linker version affects the flags that Clang pass
to the linker, notably whether it passes -demangle or not.
http://reviews.llvm.org/D6239
llvm-svn: 221844
Installing <prefix>/share/clang/cmake/ClangConfig.cmake makes CMake's
builtin find_package() utility work with Clang. This also allows
downstream consumers of Clang to statically link against libraries like
clangAST and have that pull in dependencies like clangBasic and
LLVMSupport.
See the CMake docs on packages:
http://www.cmake.org/cmake/help/v3.0/manual/cmake-packages.7.html
llvm-svn: 221411
The rewrite facility's footprint is small so it's not worth going to these
lengths to support disabling at configure time, particularly since key compiler
features now depend on it.
Meanwhile the Objective-C rewriters have been moved under the
ENABLE_CLANG_ARCMT umbrella for now as they're comparatively heavy and still
potentially worth excluding from lightweight builds.
Tests are now passing with any combination of feature flags. The flags
historically haven't been tested by LLVM's build servers so caveat emptor.
llvm-svn: 213171
Prospectively revert to get one of the many build configurations back working
(presumably the side-by-side+modular CMake config).
This reverts commit r212997.
llvm-svn: 213008
We probably just need to touch LLVM's configure this time to work around the
totally inadequate Makefile build server integration.
This reverts commit r210314.
llvm-svn: 210320
This will unbreak clang vendor builds as a follow-up to r210238, now that we
can't poke into LLVM's private config.h (nor should the string be exposed by
llvm-config.h).
This hopefully removes for good the last include of LLVM's config.h.
llvm-svn: 210313
target_link_libraries(INTERFACE) doesn't bring inter-target dependencies in add_library,
although final targets have dependencies to whole dependent libraries.
It makes most libraries can be built in parallel.
target_link_libraries(PRIVATE) is used to shaared library.
Each dependent library is linked to the target.so, and its user will not see its grandchildren.
For example,
- libclang.so has sufficient libclang*.a(s).
- c-index-test requires just only libclang.so.
FIXME: lld is tweaked minimally. Adding INTERFACE in each library would be better thing.
llvm-svn: 202241
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
This does;
- clang_tablegen() adds each tblgen'd target to global property CLANG_TABLEGEN_TARGETS as list.
- List of targets is added to LLVM_COMMON_DEPENDS.
- all clang libraries and targets depend on generated headers.
You might wonder this would be regression, but in fact, this is little loss.
- Almost all of clang libraries depend on tblgen'd files and clang-tblgen.
- clang-tblgen may cause short stall-out but doesn't cause unconditional rebuild.
- Each library's dependencies to tblgen'd files might vary along headers' structure.
It made hard to track and update *really optimal* dependencies.
Each dependency to intrinsics_gen and ClangSACheckers is left as DEPENDS.
llvm-svn: 201842
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/Clang installation, we should
not ask CMake to manage permissions of that directory for us. Instead,
give only our own include/clang and include/clang-c subdirectories to
the install(DIRECTORY) command.
Fixes PR4500. Patch by Brad King.
llvm-svn: 201076
so bump the minimum version in the standalone Clang CMake project as
well.
As I mentioned on the LLVM commit version of this, if this causes any
trouble for folks, just let me know. I'm trying to avoid re-implementing
functionality in CMake, but I will if there are problems using the newer
versions.
llvm-svn: 199152
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
Convert CMake CLANG_BUILD_EXAMPLES to a boolean value for consumption by
Python, otherwise the raw config string gets passed through which may not be
0/1.
The if/else matches the technique used to solve the problem in LLVM's own
CMakeLists.txt.
llvm-svn: 198750
Somehow the entire plugin infrastructure went wholly untested until now.
The only plugins available for use in testing are the examples, so plugin tests
will only be run if CLANG_BUILD_EXAMPLES is enabled in the build.
(The examples should really be enabled by default, not just to aid testing but
also to prevent bitrot in some key user-facing code. I'll propose that
shortly.)
Requires supporting changes in LLVM r198746.
llvm-svn: 198747
In a standalone build, Clang binaries should end up in Clang's build folder,
not LLVM's.
Xcode still has a few issues finding auxiliary tools and libraries in the
build folders. I'll fix those next.
llvm-svn: 198328
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
Also stop setting passing -dead_strip explicitly for libclang and instead
rely on this now happening by default. (And make it happen by default for
add_clang_library, which doesn't use the library cmake functions from llvm.)
llvm-svn: 198200
- If llvm-config fails, output an error to the user rather than allowing
errors to cascade.
- Always get llvm-tblgen from llvm-config's bindir.
Turns out my PATH points to a really old version of LLVM; both of these
fell out of trying to make this experience nicer.
llvm-svn: 197714
Checked on VS10(multiconfig) and some singleconfig builders.
* Assumptions
- You should specify llvm-config as LLVM_CONFIG.
CMake could find one in $PATH by default.
- ENABLE_ASSERTIONS obeys LLVM's.
* Use cases
a) With LLVM build tree
Assume llvm-config is in your build tree.
Everything should work as ever.
b) With *installed* LLVM
Assume distributions. The source tree can be optional.
b1) The source tree is provided on the location `llvm-config --src-root`
- Test utils, FileCheck &c., are imported and built in the new tree.
- Gtest is built in the tree if gtest library is not found.
- Lit is used in $(SRCROOT)/utils/lit/lit.py.
b2) The source tree is not provided
- clang and utilities can be built.
- All tests, unittests and check-clang are invalidated and not built.
llvm-svn: 197697
NAKAMURA Takumi