Unfortunately, on ELF there is not used attribute on the .o files,
so there is no easy way to keep the dump function alive.
If we are not gcing, we may as well produce non gcable files and
avoid the cost.
Linking a debug clang now takes 18.856225992 seconds, before it
took 21.206897447.
I will try avoiding --gc-sections -O3 on a followup patch.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@234159 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
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
The dependencies for cross-built tablegen were a bit confused. This fixes that. The following dependencies are now enforced:
(1) Tablegen tasks depend on the native tablegen
(2) Native tablegen depends on the cross-compiled tablegen
Although the native tablegen doesn't actually require the cross tablegen, having this dependency forces the native tablegen to rebuild whenever the cross tablegen changes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@232730 91177308-0d34-0410-b5e6-96231b3b80d8
NFC currently but required as a prerequisite for using
the Microsoft resource compiler in conjunction with
CMake's ninja generator, which knows how to filter flags
appropriately, but not definitions.
Differential Revision: http://reviews.llvm.org/D8188
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@232727 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
* put most of the cross-compiling support into a function llvm_create_cross_target_internal.
* when CrossCompile is included it still generates a NATIVE target.
* llvm_create_cross_target function takes a target_name which should match a toolchain.
* llvm_create_cross_target can now be used to target more than one cross-compilation target.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@232067 91177308-0d34-0410-b5e6-96231b3b80d8
NFC currently but required as a prerequisite for using
the Microsoft resource compiler in conjunction with
CMake's ninja generator, which knows how to filter flags
appropriately, but not definitions.
Differential Revision: http://reviews.llvm.org/D8188
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@231924 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
Introduce -mllvm -sanitizer-coverage-8bit-counters=1
which adds imprecise thread-unfriendly 8-bit coverage counters.
The run-time library maps these 8-bit counters to 8-bit bitsets in the same way
AFL (http://lcamtuf.coredump.cx/afl/technical_details.txt) does:
counter values are divided into 8 ranges and based on the counter
value one of the bits in the bitset is set.
The AFL ranges are used here: 1, 2, 3, 4-7, 8-15, 16-31, 32-127, 128+.
These counters provide a search heuristic for single-threaded
coverage-guided fuzzers, we do not expect them to be useful for other purposes.
Depending on the value of -fsanitize-coverage=[123] flag,
these counters will be added to the function entry blocks (=1),
every basic block (=2), or every edge (=3).
Use these counters as an optional search heuristic in the Fuzzer library.
Add a test where this heuristic is critical.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@231166 91177308-0d34-0410-b5e6-96231b3b80d8
This allows clang-cl to self-host cleanly with no magic setup
steps required.
After this patch, all you have to do is set CC=CXX=clang-cl and
run cmake -G Ninja.
These changes only exist to support C++ features which are
unsupported in clang-cl, so regardless of whether the user
specifies they want to use them, we still have to disable them.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230539 91177308-0d34-0410-b5e6-96231b3b80d8
It is possible for the atomic routines to be provided by the compiler without
requiring any additional libraries. Check if that is the case before checking
for a library.
Patch by Matt Glazar!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230452 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
If we're using clang-cl, that's a pretty good indication that we're
going to use MSVC's STL.
This simplifies the clang-cl ninja self-host configuration down to:
CC=clang-cl CXX=clang-cl cmake .. -GNinja
Modified version of zturner's patch:
Differential Revision: http://reviews.llvm.org/D7824
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230239 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
Instead of requiring MSVC 2013 U4, we simply warn users, since some might
not bt able to immediately upgrade.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@229598 91177308-0d34-0410-b5e6-96231b3b80d8
Previous versions of MSVC 2013 would miscompile ASTMatchers (and/or their
tests). Bump up the requirement and make sure we know about the minor
revision.
Minimum required version found by Michael Edwards!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@229584 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
Since header files are not compilation units, CMake does not require
you to specify them in the CMakeLists.txt file. As a result, unless a
header file is explicitly added, CMake won't know about it, and when
generating IDE-based projects, CMake won't put the header files into
the IDE project. LLVM currently tries to deal with this in two ways:
1) It looks for all .h files that are in the project directory, and
adds those.
2) llvm_add_library() understands the ADDITIONAL_HEADERS argument,
which allows one to list an arbitrary list of headers.
This patch takes things one step further. It adds the ability for
llvm_add_library() to take an ADDITIONAL_HEADER_DIRS argument, which
will specify a list of folders which CMake will glob for header files.
Furthermore, it will glob not only for .h files, but also for .inc
files.
Included in this CL is an update to one of the existing users of
ADDITIONAL_HEADERS to use this new argument instead, to serve as an
illustration of how this cleans up the CMake.
The big advantage of this new approach is that until now, there was no
way for the IDE projects to locate the header files that are in the
include tree. In other words, if you are in, for example,
lib/DebugInfo/DWARF, the corresponding includes for this project will
be located under include/llvm/DebugInfo/DWARF. Now, in the
CMakeLists.txt for lib/DebugInfo/DWARF, you can simply write:
ADDITIONAL_HEADER_DIRS
../../include/llvm/DebugInfo/DWARF
as an argument to llvm_add_library(), and all header files will get
added to the IDE project.
Differential Revision: http://reviews.llvm.org/D7460
Reviewed By: Chris Bieneman
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@228670 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Handle LLVM_USE_SANITIZER=Address;Undefined to enable ASan and UBSan
If UBSan is compatible with more of the other sanitizers, maybe we should
deal with this in a better way where we allow combining UBSan with any of
the other sanitizers.
Reviewers: samsonov
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D7024
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@228219 91177308-0d34-0410-b5e6-96231b3b80d8
This was added in r188351 to fix a naming conflict between the
profile_rt-static and profile_rt-shared who both ended up in
lib/profile_rt.lib.
The change also affected other libraries (like libclang), and
users are reporting that they find it surprising that there's
no longer a libclang.lib. Since the profile_rt naming conflict
doesn't seem to exist any more, I think we can remove this.
Differential Revision: http://reviews.llvm.org/D7391
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@228049 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
When LLVM_USE_SANITIZE_COVERAGE=YES
and one of the sanitizers is used -fsanitize-coverage=3 will be added
to build flag. This will be used to run a coverage-guided fuzzer on various
llvm libraries.
Test Plan: n/a
Reviewers: rnk
Reviewed By: rnk
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D7116
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@227216 91177308-0d34-0410-b5e6-96231b3b80d8
Should make the tests run when using CMake on systems where 'uname -p'
reports "amd64", such as FreeBSD.
Should fix PR21559.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@226937 91177308-0d34-0410-b5e6-96231b3b80d8
ELF linkers by default allow shared libraries to contain undefined references
and it is up to the dynamic linker to look for them.
On COFF and MachO, that is not the case.
This creates a situation where a .so might build on an ELF system, but the build
of the corresponding .dylib or .dll will fail.
This patch changes the cmake build to use -Wl,-z,defs when linking and updates
the dependencies so that -DBUILD_SHARED_LIBS=ON build still works.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@226611 91177308-0d34-0410-b5e6-96231b3b80d8
As a result, installations of LLVM in non-standard locations
will not require passing custom -ccopt -L flags when building
the binary, nor absolute paths would be embedded in the cma/cmxa
files. Additionally, the executables will not require changes
to LD_LIBRARY_PATH, although CAML_LD_LIBRARY_PATH still
has to be set for ocamlc without -custom.
See http://caml.inria.fr/mantis/view.php?id=6642.
Note that the patch is approved, but not merged yet.
It will be released in 4.03 and likely 4.02.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@225778 91177308-0d34-0410-b5e6-96231b3b80d8
Add the missing `DEPENDS` keyword. r225319 did almost the right thing
(I didn't notice the problem with it because `Kaleidoscope-Ch8` wasn't
building at all).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@225321 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This in turn allows us to use #includes with cgo that rely on CMake
provided include directories which is particularly useful for handling
generated headers that aren't reasonable to put in an "installable"
location.
Differential Revision: http://reviews.llvm.org/D6798
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@224962 91177308-0d34-0410-b5e6-96231b3b80d8
that is used by other projects to build against LLVM. This will allow
subsequent patches to them to use LLVM_LIBDIR_SUFFIX, both when built as
part of the larger LLVM build an as part of a standalone build against
an installed set of LLVM libraries.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@224920 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
The algorithm for sorting libraries in topological order, as
previously implemented, had a few issues:
* It didn't make any sense.
* It didn't actually sort libraries in topological order.
* It hung on some inputs, e.g. "LLVMipo".
This commit replaces the old algorithm with a straightforward port
from llvm-config.cpp.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@224554 91177308-0d34-0410-b5e6-96231b3b80d8
This lets the queries work on Windows as well as Linux.
This does mean make and cmake aren't using the same scripts to do the
queries (again), but at least GetSVN.cmake understands git and git-svn
as well as svn now.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223425 91177308-0d34-0410-b5e6-96231b3b80d8
Presumably it was added to the CMake system when MAXPATHLEN was still
used by code built for Windows. Currently only lib/Support/Path.inc uses
MAXPATHLEN, and it should be available on all Unices.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223139 91177308-0d34-0410-b5e6-96231b3b80d8
This allows the logic to work with Git, and also uses the variable names
to match what Clang is actually looking for.
This is a re-application of r190556 and r190808. This changes the interface
of GetSVN.cmake. Clang change to follow.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@222391 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
IMO we need to clean up some of these, but the member variable one
(C4458) has false positives on static methods. It is currently firing
on Twine, which has a static method like:
struct Twine {
uintptr_t LHS, RHS;
static void staticMethod() {
// warning C4458: declaration of 'LHS' hides class member
uintptr_t LHS;
...
}
};
We should fix up clang's -Wshadow and clean it up, and then we can
re-enable some of these MSVC warnings.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221012 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: This is a fix for the command line syntax error while building LTO when using MinGW.
Patch By: jsroemer
Reviewers: rnk
Reviewed By: rnk
Subscribers: rnk, beanz, llvm-commits
Differential Revision: http://reviews.llvm.org/D5476
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220935 91177308-0d34-0410-b5e6-96231b3b80d8
This would cause the flag to appear in the output of "llvm-config --cppflags",
which should contain only preprocessor flags. The -gsplit-dwarf flag in
particular can cause problems with certain downstream users such as cgo.
Differential Revision: http://reviews.llvm.org/D5895
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220410 91177308-0d34-0410-b5e6-96231b3b80d8
the CGO build environment. This lets things like -rpath propagate down
to the C++ code that is built along side the Go bindings when testing
them.
Patch by Peter Collingbourne, and verified that it works by me.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220252 91177308-0d34-0410-b5e6-96231b3b80d8
It dropped required functions for plugins with gnu ld 2.20 and 2.21.
Failing Tests (1):
LLVM :: Feature/load_module.ll
Hello: bin/opt: symbol lookup error: lib/LLVMHello.so: undefined symbol: _ZN4llvm11raw_ostream13write_escapedENS_9StringRefEb
Failing Tests (1):
Clang :: Frontend/plugins.c
error: unable to load plugin 'lib/PrintFunctionNames.so': 'lib/PrintFunctionNames.so: undefined symbol: _ZN5clang15PluginASTAction6anchorEv'
I think we should inspect linker's version or behavior to introduce --gc-sections for --export-dynamic.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220198 91177308-0d34-0410-b5e6-96231b3b80d8
Both bfd ld and gold correctly handle --export-dynamic, so gc-sections is safe even for binaries
that support plugins.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220174 91177308-0d34-0410-b5e6-96231b3b80d8
lldb sets the variable SHARED_LIBRARY to 1, which breaks this conditional,
because older versions of CMake interpret
if ("${t}" STREQUAL "SHARED_LIBRARY")
as meaning
if ("${t}" STREQUAL "1")
in this case. Change the conditional so it does the right thing with both old
and new CMakes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218542 91177308-0d34-0410-b5e6-96231b3b80d8
``make clean`` because it won't be available.
This is an attempt to unbreak buildbots broken by r217484.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@217490 91177308-0d34-0410-b5e6-96231b3b80d8
This fixes the generation of broken LLVMExports.cmake file by
the Autoconf/Makefile build system when --enable-shared is passed to
configure.
When --enable_shared is passed the Makefile.rules does not set the
LLVMConfigLibs variable which cmake/modules/Makefile previously relied
on. Now it runs the llvm-config command itself to get the library names.
This still isn't perfect because the generated LLVM targets refer to the
static libraries and not the shared library but that is much larger
problem to fix.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@217484 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
Some editors create hidden file backups in the same
directory as the file, and it's annoying when cmake
errors on them.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@216941 91177308-0d34-0410-b5e6-96231b3b80d8
I've fixed most of the simple bugs and currently "check-llvm" test suite
has 26 failures, and "check-clang" suite has 5 failures.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@216701 91177308-0d34-0410-b5e6-96231b3b80d8
This test was testing nothing, as only -Werror was ever
being added to the compiler flags.
You can see the final nitty-gritty compiler invocation in
CMakeFiles/CMakeOutput.log (for successful tests) and
CMakeFiles/CMakeError.log (for failed tests).
Before:
Building C object CMakeFiles/cmTryCompileExec3385359576.dir/src.c.o
/usr/bin/clang -fPIC -Wall -W -Wno-unused-parameter -Wwrite-strings -Wmissing-field-initializers -pedantic -Wno-long-long -Wcovered-switch-default -DC_WCOMMENT_ALLOWS_LINE_WRAP -Werror -o CMakeFiles/cmTryCompileExec3385359576.dir/src.c.o -c /home/nobled/code/llvm-b9/CMakeFiles/CMakeTmp/src.c
After:
Building C object CMakeFiles/cmTryCompileExec3385359576.dir/src.c.o
/usr/bin/clang -fPIC -Wall -W -Wno-unused-parameter -Wwrite-strings -Wmissing-field-initializers -pedantic -Wno-long-long -Wcovered-switch-default -DC_WCOMMENT_ALLOWS_LINE_WRAP -Werror -Wcomment -o CMakeFiles/cmTryCompileExec3385359576.dir/src.c.o -c /home/nobled/code/llvm-b9/CMakeFiles/CMakeTmp/src.c
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@216328 91177308-0d34-0410-b5e6-96231b3b80d8
clang has only been smart enough not to trigger -Wnon-virtual-dtor
warnings on final classes since r208449 (in clang 3.5). Building
with older versions is extremely noisy, so disable the warning
on those compilers.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@216327 91177308-0d34-0410-b5e6-96231b3b80d8
treated as errors (which is still the default). This is useful when
working on documentation that has existing errors.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215634 91177308-0d34-0410-b5e6-96231b3b80d8
use is deprecated in favour of llvm_map_components_to_libnames()
Although message(DEPRECATION "msg") would probably be a better fit this
does nothing if CMAKE_ERROR_DEPRECATED and CMAKE_WARNING_DEPRECATED are
both off, which is the default.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214078 91177308-0d34-0410-b5e6-96231b3b80d8
of LLVM using CMake can easily find the tools directory.
LLVM_BUILD_TOOLS_BINARY_DIR was removed because it is now
superfluous.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213674 91177308-0d34-0410-b5e6-96231b3b80d8
clients of LLVM know if RTTI and/or EH were enabled in the build of
LLVM they are trying to link against.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213664 91177308-0d34-0410-b5e6-96231b3b80d8
to globally be controlled. Individual targets (e.g. ExceptionDemo) can
still override this by using LLVM_REQUIRE_RTTI and LLVM_REQUIRE_EH if
they need to be compiled with RTTI or exception handling respectively.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213663 91177308-0d34-0410-b5e6-96231b3b80d8
Removing the native CMakeCache.txt causes the target to get re-run needlessly
on some systems. We'll want another solution for that part of the fix.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213099 91177308-0d34-0410-b5e6-96231b3b80d8
This adds support for building native artifacts when cross-compiling using the
popular side-by-side source directory layout (no symlinks, no nested
repositories).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213091 91177308-0d34-0410-b5e6-96231b3b80d8
It turns out this commit was fine. The problem was in the legacy build system (fixed r213010).
This reverts commit r213005.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213015 91177308-0d34-0410-b5e6-96231b3b80d8
This broke one of the builds, presumably side-by-side modular CMake.
Investigating.
This reverts commit r212998.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213005 91177308-0d34-0410-b5e6-96231b3b80d8
clang r212997 incorporated these settings into its own build system. They no
longer need to be set from LLVM.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@212998 91177308-0d34-0410-b5e6-96231b3b80d8
For example, c-index-test.exe requires just libclang.dll (its import library).
When libraries in libclang were not PRIVATE but PUBLIC, c-index-test required libraries transitive by libclang.
Note, on mingw with BUILD_SHARED_LIBS, library dependencies would become more strict.
In principle, required libraries should be "required in its source file".
This will help to detect missing dependencies.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@212934 91177308-0d34-0410-b5e6-96231b3b80d8
On Win32.DLL, it points not lib but bin.
LIBRARY_OUTPUT_DIRECTORY affects add_library(MODULE), especially Win32.DLL.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@212903 91177308-0d34-0410-b5e6-96231b3b80d8
This -f group flag appears to influence linker flags, breaking the usual rules
and causing CMake's link invocation to fail during feature detection due to
missing link dependencies (msan_*).
Let's forcibly add it for now to get things the way they were before feature
detection started working.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@212590 91177308-0d34-0410-b5e6-96231b3b80d8
When LLVM_ENABLE_TIMESTAMPS has been disabled we can prevent the preprocessor
from embedding dates, times and file timestamps.
There are a few motivations for this:
1) Validate the recent CMake feature detection bugfix from LLVM r212586 with
a flag that's not actually available everywhere.
2) Dogfood clang's new -Wdate-time warning from r210511 when bootstrapping.
3) Encourage reproducible builds.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@212587 91177308-0d34-0410-b5e6-96231b3b80d8
add_flag_if_supported() and add_flag_or_print_warning() were effectively
no-ops, just returning the value of the first result (usually
'-fno-omit-frame-pointer') for all subsequent checks for different flags.
Due to the way CMake caches feature detection results, we need to provide
symbolic variable names which will persist the cached results. This commit
fixes feature detection using these two macros.
The feature checks now run and get stored correctly, and the correct output can
be observed in configure logs:
-- Performing Test C_SUPPORTS_FPIC
-- Performing Test C_SUPPORTS_FPIC - Success
-- Performing Test CXX_SUPPORTS_FPIC
-- Performing Test CXX_SUPPORTS_FPIC - Success
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@212586 91177308-0d34-0410-b5e6-96231b3b80d8
FIXME: Make this configurable.
FIXME: "ENABLE_SHARED" doesn't make sense, since it is used just for plugins. We may rename it.
I introduced config.enable_shared in r120273.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@212315 91177308-0d34-0410-b5e6-96231b3b80d8
By default, CMake will set NDEBUG in Rel* builds and leave it off in
debug builds, so we shouldn't need to do anything ourselves.
Before this change, it was possible to a Debug build without assertions
(aka Debug-Asserts in the autoconf system) by configuring with
-DLLVM_ENABLE_ASSERTIONS=OFF, but this configuration isn't very useful.
You can still get the same effect by explicitly adding -DNDEBUG to
CFLAGS.
Differential Revision: http://reviews.llvm.org/D4257
Patch by Janusz Sobczak!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211919 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
add_definitions shouldn't really be used for compiler flags, and the variable
LLVM_DEFINITIONS is not appropriately used at the moment, e.g. it's not exported
to LLVMConfig.cmake
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@203792 91177308-0d34-0410-b5e6-96231b3b80d8
I personally build with these settings enabled all the time, and it
is clearer to see the actual warning flags (e.g., -Wuninitialized)
get passed by Xcode rather than seeing -Wno-uninitialized followed
by -Wall (the latter canceling out the former) and figuring out
what is going on.
Xcode will ignore build settings it doesn't understand, so this will
work on possibly older versions of Xcode that don't support all
of these settings.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@203760 91177308-0d34-0410-b5e6-96231b3b80d8
Without this common features like off_t and strdup are missing.
This should bring back those bots.
Configure bits by Meador Inge.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@203701 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
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202241 91177308-0d34-0410-b5e6-96231b3b80d8
The LLVMSupport library implementation consolidates all dependencies on
system libraries. Move the logic gathering system libraries out of
'cmake/modules/LLVM-Config.cmake' and into 'lib/Support/CMakeLists.txt'.
Use the target_link_libraries() command there to tell CMake about the
link dependencies of the LLVMSupport implementation. CMake will
automatically propagate this to all targets that link LLVMSupport
directly or indirectly.
We still need to build knowledge of system library dependencies into
'llvm-config'. Store the list of libraries needed in a property on
LLVMSupport and teach 'tools/llvm-config/CMakeLists.txt' to retrieve it
from there.
Drop all calls to 'link_system_libs' and 'get_system_libs' from our
CMake code. Replace their implementations with a warning that explains
the calls are no longer necessary. Also drop from 'LLVMConfig.cmake'
the HAVE_* and related variables that were published there only to allow
'get_system_libs' to run outside our build process.
Contributed by Brad King.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201969 91177308-0d34-0410-b5e6-96231b3b80d8
llvm_add_library(foo SHARED STATIC
DEPENDS <dependent targets...>
LINK_LIBS <required libraries...>
)
It generates both foo (foo.so) and foo_static(foo.a) and both of them depend on DEPENDS and LINK_LIBS.
Then, also obj.foo is generated. obj.foo depends on DEPENDS, but doesn't depend on LINK_LIBS.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201854 91177308-0d34-0410-b5e6-96231b3b80d8
The module still needs to collect the list of all available libraries
in order to satisfy the 'all' component. Provide this in the package
configuration file, 'LLVMConfig.cmake', as a LLVM_AVAILABLE_LIBS
variable. (A variable is scoped better than a global property.)
Since this won't be set for our own build, fall back to looking up the
LLVM_LIBS property to get the value when it is not set.
Contributed by Brad King.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201853 91177308-0d34-0410-b5e6-96231b3b80d8
LLVM library names are now available as logical CMake targets both
to our own build and to application CMake code. Replace use of
'list(FIND)' with a simple 'if(TARGET)' to determine whether a
library is available.
Contributed by Brad King.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201852 91177308-0d34-0410-b5e6-96231b3b80d8
On unsupported platforms, llvm_add_library(MODULE) doesn't create any targets.
Caller may be responsible to check and add extra target properties.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201320 91177308-0d34-0410-b5e6-96231b3b80d8
FIXME: llvm/test may be aware of LLVM_PLUGIN_EXT, like as clang/test does.
FIXME: CMAKE_*_SUFFIX may be set in HandleLLVMOptions if those variables could be writable, rather than to set one as target properties.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201316 91177308-0d34-0410-b5e6-96231b3b80d8
I was insightless then about unknown optional parameters.
(Consider that LINK_LIBS foo bar ADDITIONAL_HEADERS qux quux)
Suggested by Michael Kruse. Thanks!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201283 91177308-0d34-0410-b5e6-96231b3b80d8
This macro depends on several variables to be set in the calling
context. Check them and report an error if they are not set.
Without this, custom commands may be silently specified that
will fail at build time.
Patch by Brad King.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201229 91177308-0d34-0410-b5e6-96231b3b80d8
- MODULE;SHARED;STATIC
STATIC by default w/o BUILD_SHARED_LIBS.
SHARED by default w/ BUILD_SHARED_LIBS.
- OUTPUT_NAME name
Corresponds to OUTPUT_NAME in target properties.
- DEPENDS targets...
Same semantics as add_dependencies().
- LINK_COMPONENTS components...
Same as the variable LLVM_LINK_COMPONENTS.
- LINK_LIBS lib_targets...
Same semantics as target_link_libraries().
- ADDITIONAL_HEADERS (implemented in LLVMProcessSources)
May specify header files for IDE generators.
I suggest llvm_add_library() may be used for inter-project add_library stuff
and also suggest add_***_library() may be used project-specific.
Please be patient that llvm_add_library might be ambiguous against add_llvm_library.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201072 91177308-0d34-0410-b5e6-96231b3b80d8
I am sure it'd not be required any more.
In trunk, all of tablegen's users depend on ${TABLEGEN_OUTPUT} as not file dependency but inter-target dependency.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201063 91177308-0d34-0410-b5e6-96231b3b80d8
CMake's target_link_libraries() will manage dependencies with Brad's LLVMConfig improvements.
Configuration time may be reduced by a few seconds.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201062 91177308-0d34-0410-b5e6-96231b3b80d8
You can't put a comment in the middle of a command like this. This is
invalid shell syntax and breaks the build.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201057 91177308-0d34-0410-b5e6-96231b3b80d8
Teach the Makefile build system to generate and install CMake modules
LLVMConfig.cmake and LLVMConfigVersion.cmake so that applications that
build with CMake can use 'find_package(LLVM)' even when LLVM is not
built with CMake. These modules tell such applications about available
LLVM libraries and their dependencies.
Run llvm-config to generate the list of libraries and use the results of
llvm-build to generate the library dependencies. Use sed to perform
substitutions in the LLVMConfig.cmake.in and LLVMConfigVersion.cmake.in
sources that our CMake build system uses.
Teach the Makefile build system to generate the LLVMExports.cmake file
with content similar to that produced by the CMake install(EXPORT)
command. Extend llvm-build with an option to generate the library
dependencies fragment for this file.
Contributed by Brad King.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201053 91177308-0d34-0410-b5e6-96231b3b80d8
Teach each package configuration file to load the LLVMExports file for
its corresponding tree. This will allow application CMake code to use
logical library and executable target names from LLVM as if they were in
our own build process (e.g. LLVMSupport). CMake will have enough
information to propagate LLVM library link dependencies automatically
while configuring applications.
Contributed by Brad King.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201051 91177308-0d34-0410-b5e6-96231b3b80d8
Record every logical target that we install with install(TARGETS) in a
global LLVM_EXPORTS property. Then use the export(TARGETS) command to
provide a "LLVMExports.cmake" file that exports logical targets for
import into applications directly from our build tree.
The "LLVMExports.cmake" file is not meant for direct inclusion by
application code but should be included by "LLVMConfig.cmake" in a
future change.
Contributed by Brad King.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201050 91177308-0d34-0410-b5e6-96231b3b80d8
Use the install(TARGETS) command EXPORT option for every library and
executable that we install with LLVM. Then use the install(EXPORT)
command to provide a "LLVMExports.cmake" file that exports logical
targets for import into applications from our install tree.
The "LLVMExports.cmake" file is not meant for direct inclusion by
application code but should be included by "LLVMConfig.cmake" in a
future change.
Contributed by Brad King.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201049 91177308-0d34-0410-b5e6-96231b3b80d8
Create separate package configuration files "LLVMConfig.cmake" for the
LLVM build and install trees so that each can have information specific
to its tree. Configure each with the corresponding include, lib, and
cmake directories. Include the "LLVM-Config" API modules directly from
the configured cmake modules directory.
In the install tree, compute the installation prefix relative to the
file location. In the build tree, provide information specific to the
build tree for use by tools like Clang that can build externally against
the LLVM build tree. Prefix such values in "LLVM_BUILD_" and comment
them as such.
Contributed by Brad King.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201048 91177308-0d34-0410-b5e6-96231b3b80d8
Do not modify this value on the application's behalf and just ensure API
modules are always available next to the LLVMConfig module. This is
already the case in the install tree so use file(COPY) to make it so in
the build tree. Include the LLVM-Config API module from next to the
LLVMConfig location.
Contributed by Brad King.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201047 91177308-0d34-0410-b5e6-96231b3b80d8
Use a LLVM_INSTALL_PACKAGE_DIR variable to hold the path and reference
it where necessary.
Contributed by Brad King.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201046 91177308-0d34-0410-b5e6-96231b3b80d8
CMake won't expand the dependency graph for us if the dependencies are in
another project, which leads to link errors in the standalone build.
This is a refinement of r200765.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200812 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
CMake's target_link_libraries() will manage dependencies.
Configuration time may be reduced by a few seconds.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200765 91177308-0d34-0410-b5e6-96231b3b80d8
In trunk, every users assume add_llvm_loadable_module as "loadable module" and no one sets neither SHARED, ... nor also MODULE!
Unfortunately, all loadable modules were linked as not "MODULE" but "SHARED".
If this change caused any regressions, I wish guys to fix it properly. ;)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200762 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
It missed include/llvm/Target. Could I avoid GLOB_RECURSE anyways? :(
FYI, I intended to prune ${LLVM_MAIN_INCLUDE_DIR} in TableGen.cmake in r200150.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200730 91177308-0d34-0410-b5e6-96231b3b80d8
This will disable -ffunction-sections in older versions of Clang where it
breaks build of sanitizer runtime library.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200695 91177308-0d34-0410-b5e6-96231b3b80d8
LLVM_REQUIRES_EH implies LLVM_REQUIRES_RTTI. It is as same behavior as Makefile.rule's.
llvm/examples/ExceptionDemo is affected. (It was built with -fno-rtti.)
For MSVC, Remove flags like "/EHsc /GR" in HandleLLVMOptions, or CL.EXE complains with flags like "/GR /GR-".
llvm_update_compile_flags() updates source file property if the target contains *.c.
COMPILE_FLAGS in target properties affects both C++ and C!
LLVM_NO_RTTI is deprecated. It was introduced by me and was my mistake.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200301 91177308-0d34-0410-b5e6-96231b3b80d8
With this tweaks, also unittests are compiled with -ffunction-sections.
It's hard to control contextual CMAKE_CXX_FLAGS. We should get rid of twiddling it as possible.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200299 91177308-0d34-0410-b5e6-96231b3b80d8
ADDITIONAL_HEADERS is intended to add header files for IDEs as hint.
For example:
add_llvm_library(LLVMSupport
Host.cpp
ADDITIONAL_HEADERS
Unix/Host.inc
Windows/Host.inc
)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199639 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
accidentally pick that up while using Clang and run into subtle bugs
down the road related to C++11 features not fully implemented in that
version of the standard library.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199484 91177308-0d34-0410-b5e6-96231b3b80d8
The generation of the native_export_file end up in
several different makefiles. All those makefiles
write the same file, but can be executed concurrently...
and bad things happen!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199356 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
This is needed to support the addition of tests for clang loadable plugins.
In clang, plugins are built as modules (bundles on OS X) rather than dynamic
libraries (dylib) so the build system needs to inform lit of the actual
file extension in use, typically '.so' on Unix and '.dll' on Windows.
(LLVM itself should probably switch to this scheme to fix PR14903 once and for
all.)
No change in build output or functionality intended.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@198746 91177308-0d34-0410-b5e6-96231b3b80d8
Plugins need to go in build/Debug/lib as well (rather than build/lib/Debug).
Also, fix the SHLIBDIR path for Xcode, which by default includes Xcode build
settings rather than a simple %(build_mode)s parameter.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@198344 91177308-0d34-0410-b5e6-96231b3b80d8
When building Clang separately from LLVM with CMake, one should set
the path of llvm-config via the cache variable LLVM_CONFIG.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@198316 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
r198153 fixed the msvs bot problem, but broke a msysgit bot. This change
hopefully makes both variants happy.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@198156 91177308-0d34-0410-b5e6-96231b3b80d8
The windows ninja build is now green, but msvs is still unhappy. Maybe that's
because the .def file was passed when building LTO_static, so only pass
symbol lists for shared libraries.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@198151 91177308-0d34-0410-b5e6-96231b3b80d8
The command that cmd.exe is complaining about is:
cmd.exe /c cd /D C:\bb-win7\cmake-clang-i686-mingw32\build\tools\lto && cmake -E echo EXPORTS > symbol.def && type C:/bb-win7/cmake-clang-i686-mingw32/llvm-project/llvm/tools/lto/lto.exports >> symbol.def
Maybe quoting the filename helps.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@198140 91177308-0d34-0410-b5e6-96231b3b80d8
The cmake build didn't support EXPORTED_SYMBOL_FILE. Instead, it had a
Windows-only implementation in tools/lto/CMakeLists.txt, a linux-only
implementation in tools/gold/CMakeLists.txt, and a darwin-only implementation
in tools/clang/tools/libclang/CMakeLists.txt.
This attempts to consolidate these one-offs into a single place. Clients can now
just set LLVM_EXPORTED_SYMBOL_FILE and things (hopefully) Just Work, like in
the make build.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@198136 91177308-0d34-0410-b5e6-96231b3b80d8
This changes Clang standalone builds so that clang-tblgen lives in
clang/build/bin instead of llvm/build/bin, and so that with the Xcode
generator it's in clang/build/bin/Debug instead of llvm/build/bin/Debug/Debug/.
Yes, really.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197590 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
I think, in principle, intrinsics_gen may be added explicitly.
That said, it can be added incidentally, since each target already has dependencies to llvm-tblgen.
Almost all source files depend on both CommonTaleGen and intrinsics_gen.
Explicit add_dependencies() have been pruned under lib/Target.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195929 91177308-0d34-0410-b5e6-96231b3b80d8
