This is a workaround for PR39053 which was uncovered by D50652 when
the default attribute has been changed from internal_linkage to
always_inline.
Differential Revision: https://reviews.llvm.org/D52402
llvm-svn: 342833
When building libc++ for Fuchsia, we want to distribute shared libc++,
libc++abi and libunwind as separate libraries, but for static versions
we would like to link all of them into libc++ so -lc++ flag has the same
effect whether shared or static library is being used.
Differential Revision: https://reviews.llvm.org/D49628
llvm-svn: 337877
When building runtimes for Linux as part of Fuchsia toolchain, use
libc++ and compiler-rt for sanitizers.
Differential Revision: https://reviews.llvm.org/D49331
llvm-svn: 337117
This is currently breaking because Linux target sysroots rely on
case sensitive filesystem which is not by default enabled on macOS.
Differential Revision: https://reviews.llvm.org/D48710
llvm-svn: 335919
First stage build is only a minimal build where we don't need
a complete multiarch support, but we need enough to build the
second stage.
Differential Revision: https://reviews.llvm.org/D48707
llvm-svn: 335917
Previously we were using default logic when building Linux runtimes
in Fuchsia toolchain, but that leads to various issues due to how
the CMake logic in compiler-rt for determining the platform support
is implemented. With this change, we will use explicit target for
every provided Linux sysroot.
Differential Revision: https://reviews.llvm.org/D48563
llvm-svn: 335812
Now that the structure of Fuchsia SDK has been formalized, we no
longer need to pass all the different CFLAGS/LDFLAGS to the CMake
build separately, we can simply set the FUCHSIA_SDK variable and
derive all the necessary variables from that one inside the cache
file.
Differential Revision: https://reviews.llvm.org/D48564
llvm-svn: 335708
We want to build the second stage compiler with libc++ and compiler-rt,
also include builtins and runtimes into extra bootstrap components to
ensure these get built.
Differential Revision: https://reviews.llvm.org/D47356
llvm-svn: 334445
This enables the use of install-distribution-stripped target in the
2-stage builds.
Differential Revision: https://reviews.llvm.org/D47758
llvm-svn: 334063
This doesn't make any difference since we don't use RPATH/RUNPATH
on Fuchsia but it avoids the CMake error when re-linking libraries
while building with Ninja.
Differntial Revision: https://reviews.llvm.org/D46610
llvm-svn: 331833
This allows passing additional CMake flags to builtins and runtimes
build through Fuchsia cache files.
Differential Revision: https://reviews.llvm.org/D45997
llvm-svn: 331717
This changes some aspects of the build that are not relevant or useful
for Fuchsia like setting the RPATH/RUNPATH.
Differential Revision: https://reviews.llvm.org/D46361
llvm-svn: 331425
This is necessary in order to get a working C++ compiler on Darwin
since Clang expects libc++ headers to be part of the toolchain.
Differential Revision: https://reviews.llvm.org/D46075
llvm-svn: 330855
Found via codespell -q 3 -I ../clang-whitelist.txt
Where whitelist consists of:
archtype
cas
classs
checkk
compres
definit
frome
iff
inteval
ith
lod
methode
nd
optin
ot
pres
statics
te
thru
Patch by luzpaz! (This is a subset of D44188 that applies cleanly with a few
files that have dubious fixes reverted.)
Differential revision: https://reviews.llvm.org/D44188
llvm-svn: 329399
The Clang driver doesn't currently know how to use the libraries
that are shipped as part of the toolchain so there's no reason to
ship them at all.
Differential Revision: https://reviews.llvm.org/D44724
llvm-svn: 328114
Fuchsia already defaults to libc++ and compiler-rt, but we want to use
these as default runtimes even on the host platform.
Differential Revision: https://reviews.llvm.org/D39930
llvm-svn: 327860
Now that almost all functionality of Apple's dsymutil has been
upstreamed, the open source variant can be used as a drop in
replacement. Hence we feel it's no longer necessary to have the llvm
prefix.
Differential revision: https://reviews.llvm.org/D44527
llvm-svn: 327790
libClang is used by other Clang based tools such as cquery while
clang-include-fixer is generally a useful tool.
Differential Revision: https://reviews.llvm.org/D43404
llvm-svn: 325665
Enable assertions in both stages.
Release+Asserts is fast enough.
No need to let insanity through.
Patch By: mcgrathr
Reviewers: phosek
Reviewed By: phosek
Differential Revision: https://reviews.llvm.org/D41471
llvm-svn: 321316
Use this function to create the install targets rather than doing so
manually, which gains us the `-stripped` install targets to perform
stripped installations.
Differential Revision: https://reviews.llvm.org/D40675
llvm-svn: 319489
It's used to determine whether terminal supports colors, but within LLVM
it's only used in handful of places and in Clang it's only used in AST
dumper, otherwise Clang relies on the -fcolor-diagnostics flag which we
pass explicitly from our build system anyway. This eliminates one of the
shared libraries dependencies making the toolchain less reliant on the
host environment.
Differential Revision: https://reviews.llvm.org/D40329
llvm-svn: 319088
The support for relax relocations is dependent on the linker and
different toolchains within the same compiler can be using different
linkers some of which may or may not support relax relocations.
Give toolchains the option to control whether they want to use relax
relocations in addition to the existing (global) build system option.
Differential Revision: https://reviews.llvm.org/D39831
llvm-svn: 318816
Summary:
Don't use BUILD_IN_SOURCE keep git checkout clean
Don't forward CMAKE_GENERATOR as ExternalProject_Add should do it already
Reset UPDATE_COMMAND to avoid git checkout updates on each build
Reviewers: kcc, morehouse
Subscribers: cfe-commits, mgorny
Differential Revision: https://reviews.llvm.org/D39445
llvm-svn: 317035
This is nedeeded for the toolchain to be actually usable as a host
toolchain on Darwin.
Differential Revision: https://reviews.llvm.org/D39273
llvm-svn: 316542
This is a "Does your linker support it?" option, and all ours do.
Patch by Roland McGrath
Differential Revision: https://reviews.llvm.org/D37785
llvm-svn: 313173
As of now, libFuzzer is located in compiler-rt and is bundled with
Clang's toolchain by default.
Differential Revision: https://reviews.llvm.org/D37037
llvm-svn: 311514
Summary:
The clang-proto-fuzzer models a subset of C++ as a protobuf and
uses libprotobuf-mutator to generate interesting mutations of C++
programs. Clang-proto-fuzzer has already found several bugs in
Clang (e.g., https://bugs.llvm.org/show_bug.cgi?id=33747,
https://bugs.llvm.org/show_bug.cgi?id=33749).
As with clang-fuzzer, clang-proto-fuzzer requires the following
cmake flags:
- CMAKE_C_COMPILER=clang
- CMAKE_CXX_COMPILER=clang++
- LLVM_USE_SANITIZE_COVERAGE=YES // needed for libFuzzer
- LLVM_USE_SANITIZER=Address // needed for libFuzzer
In addition, clang-proto-fuzzer requires:
- CLANG_ENABLE_PROTO_FUZZER=ON
clang-proto-fuzzer also requires the following dependencies:
- binutils // needed for libprotobuf-mutator
- liblzma-dev // needed for libprotobuf-mutator
- libz-dev // needed for libprotobuf-mutator
- docbook2x // needed for libprotobuf-mutator
- Recent version of protobuf [3.3.0 is known to work]
A working version of libprotobuf-mutator will automatically be
downloaded and built as an external project.
Implementation of clang-proto-fuzzer provided by Kostya
Serebryany.
https://bugs.llvm.org/show_bug.cgi?id=33829
Reviewers: kcc, vitalybuka, bogner
Reviewed By: kcc, vitalybuka
Subscribers: thakis, mgorny, cfe-commits
Differential Revision: https://reviews.llvm.org/D36324
llvm-svn: 310408
Summary: Thoes files are used to build Android toolchain. D32816 makes it possible to build runtimes for targets.
Reviewers: beanz, srhines
Reviewed By: srhines
Subscribers: pirama, jroelofs, srhines, cfe-commits, mgorny
Differential Revision: https://reviews.llvm.org/D33561
llvm-svn: 309407
By creating this target other projects that depend on clang-generated headers (like LLDB) will no longer be order-dependent on Clang being processed by CMake first.
Also, by creating a dummy of this target in ClangConfig.cmake, projects that can build against out-of-tree clang can freely depend on the target without needing to have conditionals for if clang is in-tree or out-of-tree.
llvm-svn: 309390
Fuchsia has always been using ABI version 2 but I forgot this option
when setting up the cache file for runtimes build.
Differential Revision: https://reviews.llvm.org/D35705
llvm-svn: 308705
Also comes with a cmake cache for building the runtime bits:
$ cmake <normal cmake flags> \
-DBAREMETAL_ARMV6M_SYSROOT=/path/to/sysroot \
-DBAREMETAL_ARMV7M_SYSROOT=/path/to/sysroot \
-DBAREMETAL_ARMV7EM_SYSROOT=/path/to/sysroot \
-C /path/to/clang/cmake/caches/BaremetalARM.cmake \
/path/to/llvm
https://reviews.llvm.org/D33259
llvm-svn: 303873
-gline-tables-only. The memory consumption is apparently still too
much for some of the green dragon builders.
<rdar://problem/28672159>
llvm-svn: 302740
Green dragon had a green stage2 modules bot for a long time now[1] and
it is time to retire it and make a modules build the default for
Apple-style stage2 builds.
This patch switches the debug info generation from -gline-tables-only
to -g since full debug info does no longer cause any memory issues
even for full LTO builds [2].
[1] http://green.lab.llvm.org/green/job/clang-stage2-cmake-modulesRDA_build/
[2] http://llvm.org/devmtg/2015-10/#talk19
rdar://problem/28672159
llvm-svn: 302685
This is still used by some users of Fuchsia toolchain. Also include
llc and opt which is useful for development and testing.
Differential Revision: https://reviews.llvm.org/D32231
llvm-svn: 300917
Add the 'z3' subdirectory to the list of possible path suffixes for
libz3 header search. The z3 headers are installed in /usr/include/z3
on Gentoo.
Differential Revision: https://reviews.llvm.org/D31756
llvm-svn: 299813
Summary:
This change should fixes the export of CLANG_INCLUDE_DIRS variable in ClangConfig.cmake.
Unlike for the other variables, CLANG_INSTALL_PREFIX wasn't escaped meaning CLANG_INCLUDE_DIRS
resulting in the path "/include" instead of "${CLANG_INSTALL_PREFIX}/include".
Reviewers: beanz
Subscribers: mgorny
Differential Revision: https://reviews.llvm.org/D30911
llvm-svn: 298424
These cache files can be used to build Fuchsia toolchain. They also
demonstrate the use of multi-target builtins build.
Differential Revision: https://reviews.llvm.org/D26654
llvm-svn: 295480
Include a path hint for find_package() in ClangConfig.cmake to ensure
that CMake prefers LLVM installed alongside clang over the default
search path.
If two versions of LLVM are installed in the system, and one of them is
in PATH, CMake's find_package() magic prefers the CMake directory
alongside that install by default. Adding a relative hint makes it
possible to prioritize to the install from which find_package() is
called.
If you want to build e.g. LLDB against another install of LLVM, you can
pass LLVM_CONFIG override. In this case, LLDB queries the prefix from
llvm-config and uses the CMake files located there. However, when
including ClangConfig, the implicit find_package() nevertheless prefers
PATH-found LLVM over the one used previously by LLDB, and two versions
of LLVMConfig end up being loaded.
This could be fixed on LLDB end up by explicitly forcing custom package
search location. However, it seems simpler and safer to add a hint to
ClangConfig than to track every usage of ClangConfig.
Differential Revision: https://reviews.llvm.org/D29304
llvm-svn: 293632
When using LLVM_DISTRIBUTION_COMPONENTS, it's possible for clang's
export list to be empty. If this happens the install(EXPORTS) command
will fail, but since there isn't anything to install anyway we really
just want to skip it.
llvm-svn: 286210
We need to apply the same export logic in clang as in llvm for
LLVM_DISTRIBUTION_COMPONENTS, or the clang exports will be invalid
when we use this config.
This makes using distribution components without setting
LLVM_TOOLCHAIN_ONLY=On work correctly.
llvm-svn: 286181
These cache file are provided as an example of how to set up simple multi-stage CMake builds. I have a batch of documentation updates for LLVM.org which reference these files.
llvm-svn: 285206
This is needed by downstream projects such as swift to get proper cmake
dependency information for LLVM/Clang targets.
A few months ago I added support for exporting this information for Clang
libraries. In order to be incremental, I did not add support for exporting clang
tools as well at that time. Now such support is needed, so I am committing this
incremental code.
llvm-svn: 284658
The Xcode toolchain targets are useful on OS X hosts because you can construct and install multiple toolchians that can be used seamlessly.
llvm-svn: 278987
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
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
This ensures that the values do not bleed over in between computations. It may
make sense in the future to just refactor this code into functions to provide
"true scoping".
llvm-svn: 274179
This is an obvious bug since ClangConfig.cmake looks for ClangTargets.cmake in
${CMAKE_CURRENT_LIST_DIR}. But ClangTargets.cmake is in
${CMAKE_BINARY_DIR}/${CLANG_INSTALL_PACKAGE_DIR}, so it will always fail with an
in tree build.
In the case where clang is built out of tree, this is still correct since
CMAKE_BINARY_DIR and CLANG_BINARY_DIR will be the same.
llvm-svn: 274168
The Apple stage2 build should include compiler-rt iOS libraries and be built with the stage2 compiler. This matches Apple's production clang builds.
llvm-svn: 267584
This is a big update that gets the public configurations more in line with the ones we're actually using internally to ship Clang in Xcode.
From here forward I expect most of the changes in these files to be incremental as the changes get made internally.
llvm-svn: 263483
This patch causes the 3-stage build pipeline to only build a host compiler in the first stage, and to build all targets for subsequent stages. The host target is determined via the Native target specifier added in r262070.
llvm-svn: 262071
ClangConfig requires LLVMConfig, so add find_package call in
ClangConfig so find_package(clang REQUIRED CONFIG) will just work. This
makes it easier for cmake based projects to use clang, e.g., tools using
ClangTooling.
Patch by Don Hinton
Differential Revision: http://reviews.llvm.org/D13622
llvm-svn: 261290
I had hoped this would work from a single cache file, but turns out there is a bug I can't quite figure out relating to passing list arguments to recursive CMake invocations.
This change works around that.
llvm-svn: 260340
This cache file can be used to generate a 3-stage clang build. You can configure using the following CMake command:
cmake -C <path to clang>/cmake/caches/3-stage.cmake -G Ninja <path to llvm>
You can then run "ninja stage3-clang" to build stage1, stage2 and stage3 clangs.
This is useful for finding non-determinism the compiler by verifying that stage2 and stage3 are identical.
llvm-svn: 260201
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
Summary:
These CMake cache scripts are my first pass at replicating Apple's packaging logic from autoconf. They can be used on any Darwin machine to approximate an Apple Clang build.
The included README file includes documentation and a sample CMake invocation.
Reviewers: chandlerc, echristo
Subscribers: echristo, cfe-commits
Differential Revision: http://reviews.llvm.org/D12817
llvm-svn: 247726
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
Petr Hosek