When building a plugin against an installed LLVM toolchain using
add_llvm_loadable_module (in the documented manner) doesn't work as nothing sets
the *_OUTPUT_INTDIR variables causing an error when set_output_directory is
called. Making those arguments optional (causing the default output directory
to be used) fixes this.
Differential Revision: http://reviews.llvm.org/D13215
llvm-svn: 248911
When using LLVMConfig.cmake from an installed toolchain in order to build a
loadable pass using add_llvm_loadable_module LLVM_ENABLE_PLUGINS and
LLVM_PLUGIN_EXT must be set. Also make LLVM_DEFINITIONS be set to what it
actually is.
Differential Revision: http://reviews.llvm.org/D13214
llvm-svn: 248884
Currently LLVM_COMPILER_IS_GCC_COMPATIBLE is set as a side-effect of determining
the stdlib to use in HandleLLVMStdlib, which causes problems when attempting to
use AddLLVM from an installed LLVM toolchain, as HandleLLVMStdlib is not used.
Move the setting of this variable into DetermineGCCCompatible and include that
from both AddLLVM and HandleLLVMStdlib.
Differential Revision: http://reviews.llvm.org/D13216
llvm-svn: 248798
In order to support building clang out-of-tree the install_symlink script needs to be installed, and it needs to be found by searching the CMAKE_MODULE_PATH.
This change renames install_symlink -> LLVMInstallSymlink so it doesn't conflict with naming from other projects, and adds searching behavior in AddLLVM.cmake
llvm-svn: 248009
Summary: This change generalizes symlink generation and makes symlinks to tools obey LLVM_TOOLCHAIN_TOOLS. It makes it so that if you exclude llvm-ar from LLVM_TOOLCHAIN_TOOLS you don't end up with broken symlinks to llvm-lib and llvm-ranlib in your install.
Reviewers: bogner, chapuni, rafael
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D12864
llvm-svn: 247632
Fix-up for r247305 to use the right variable. There's another use of
LLVM_SOURCE_DIR in this file that is probably also questionable, but it's
for Windows so I'm going to leave it alone.
llvm-svn: 247311
This amends chapuni's r246156 to handle an Xcode quirk, one even called out
in the CMake documentation:
Some native build systems may not like targets that have only object files,
so consider adding at least one real source file to any target that
references $<TARGET_OBJECTS:objlib>.
I've limited the scope of this hack to Xcode for now.
llvm-svn: 247305
Summary:
Cross-compilation uses recursive cmake invocations to build native host
tools. These recursive invocations only forward a fixed set of
variables/options, since the native environment is generally the default.
This change adds -DLLVM_TARGET_IS_CROSSCOMPILE_HOST=TRUE to the recursive
cmake invocations, so that cmake files can distinguish these recursive
invocations from top-level ones, which can explain why expected options
are unset.
LLILC will use this to avoid trying to generate its build rules in the
crosscompile native host target (where it is not needed), which would fail
if attempted because LLILC requires a cmake variable passed on the command
line, which is not forwarded in the recursive invocation.
Reviewers: rnk, beanz
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D12679
llvm-svn: 247151
Summary:
This diff attempts to address the concerns raised in
http://reviews.llvm.org/D12488.
We introduce a new USE_SHARED option to llvm_config,
which, if set, causes the target to be linked against
libLLVM.
add_llvm_utility now uniformly disables linking against
libLLVM. These utilities are not intended for distribution,
and this keeps the option handling more centralised.
llvm-shlib is now processes before any other "tools"
subdirectories, ensuring the libLLVM target is defined
before its dependents.
One main difference from what was requested: llvm_config
does not prune LLVM_DYLIB_COMPONENTS from the components
passed into explicit_llvm_config. This is because the "all"
component does something special, adding additional
libraries (namely libLTO). Adding the component libraries
after libLLVM should not be a problem, as symbols will be
resolved in libLLVM first.
Finally, I'm not really happy with the
DISABLE_LLVM_LINK_LLVM option, but I'm not sure of a
better way to get the following:
- link all tools and shared libraries to libLLVM if
LLVM_LINK_LLVM_DYLIB is set
- some way of explicitly *not* doing so for utilities
and libLLVM itself
Suggestions for improvement here are particularly welcome.
Reviewers: beanz
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D12590
llvm-svn: 246918
Currently, if you call cmake with a typo in an LLVM_USE_SANITIZER
value, there's a cmake warning and the build goes on with no
sanitizers at all. This isn't a good behaviour, since cmake warnings
are fairly easy to miss and the resulting behaviour is that it looks
like the build is sanitizer clean.
Upgrade these warnings to errors so misconfigurations are more
obvious.
llvm-svn: 246531
Summary:
Three closely related changes, to have a mode in which we link all
executables and shared libraries against libLLVM.
1. Add a new LLVM_LINK_LLVM_DYLIB cmake option, which, when ON, will link
executables and shared libraries against libLLVM. For this to work, it
is necessary to also set LLVM_BUILD_LLVM_DYLIB and LLVM_DYLIB_EXPORT_ALL.
It is not strictly necessary to set LLVM_DISABLE_LLVM_DYLIB_ATEXIT, but
we also default to OFF in this mode, or tools tend to misbehave (e.g.
stdout may not flush on exit when output is buffered.)
llvm-config and Tablegen do not use libLLVM, as they are dependencies of
libLLVM.
2. Modify llvm-go to take a new flag, "linkmode=component-libs|dylib".
Depending on which one is passed (default is component-libs), we link
with the individual libraries or libLLVM respectively. We pass in dylib
when LLVM_LINK_LLVM_DYLIB is ON.
3. Fix LLVM_DYLIB_EXPORT_ALL on Linux, and expand the symbols exported to
actually export all. Don't strip leading underscore from symbols on Linux,
and make sure we get all exported symbols and weak-with-default symbols
("W" in nm output). Without these changes, passes won't load because
the "Annotate..." symbols defined in lib/Support/Valigrind.cpp are not
found.
Testing:
- Ran default build ("ninja") with LLVM, clang, compiler-rt, llgo, lldb.
- Ran "check", "check-clang", "check-tsan", "check-libgo" targets. I've
never had much success with LLDB tests, and llgoi is currently broken
so check-llgo fails for an unrelated reason.
- Ran "lldb" to ensure it loads.
Reviewers: chandlerc, beanz, pcc, rnk
Subscribers: rnk, chapuni, sylvestre.ledru, llvm-commits
Differential Revision: http://reviews.llvm.org/D12488
llvm-svn: 246527
If corresponding in-tree subdirectory exists, just ignore LLVM_EXTERNAL* stuff.
Otherwise, set LLVM_TOOL_*_BUILD ON/OFF properly according to LLVM_EXTERNAL_*.
This makes easier to walk among old revisions *without* deleteing CMakeCache.txt.
Before r242059, LLVM_EXTERNAL_* was working like;
if(EXISTS ${*_SOURCE_DIR}/CMakeLists.txt)
set(*_BUILD ON CACHE)
if(*_BUILD is ON)
add_subdirectory(*_SOURCE_DIR)
endif()
endif()
llvm-svn: 245782
gtest and gtest_main) when generating ``Makefile.llvmbuild``.
Libraries that are not installed should not be exported because they
won't be available from an install tree. Rather than filtering out the
gtest libraries in cmake/modules/Makefile, simply teach llvm-build to
filter out libraries that will not be installed from its generated list
of exported libraries.
Note that LLVMBUILD_LIB_DEPS_* are used during our own CMake build
process so we cannot filter LLVMBUILD_LIB_DEPS_gtest* out in llvm-build.
We must leave this gtest filter logic in cmake/modules/Makefile.
llvm-svn: 245718
Brad King.
Move `LLVM_LIBS_TO_EXPORT` over to Makefile.llvmbuild and generate it
from `llvm-build` using the same logic used to export the dependencies
of these libraries. This avoids depending on `llvm-config`.
This refactoring was originally motivated by issue #24154 due to commit
r243297 (Fix `llvm-config` to emit the linker flag for the combined
shared object, 2015-07-27) changing the output of `llvm-config --libs`
to not have the individual libraries when we configure with
`--enable-shared`. That change was reverted by r244108 but this
refactoring makes sense on its own anyway.
llvm-svn: 245717
such as std::equal on the third argument. This reverts previous workarounds.
Predefining _DEBUG_POINTER_IMPL disables Visual C++ 2013 headers from defining
it to a function performing the null pointer check. In practice, it's not that
bad since any function actually using the nullptr will seg fault. The other
iterator sanity checks remain enabled in the headers.
Reviewed by Aaron Ballmanþ and Duncan P. N. Exon Smith.
llvm-svn: 245711
This reverts commit r244633.
We aren't going to be able to use it because the compiler-rt build can
be built standalone without an LLVM source dir *or* an installed copy of
LLVM.
llvm-svn: 244648
If we don't have sys/wait.h and we're on a unix system there's no way
that several of the llvm tools work at all. This includes clang.
Just remove the configure and cmake checks entirely - we'll get a
build error instead of building something broken now.
llvm-svn: 243957
This allows asm files and Cxx files to be compiled with different flags
rather than treating them identically. LLVM itself has no asm files
other than tests, but this setting is inherited by the compiler-rt
project (unless compiled standalone), which does have asm files.
Differential Revision: http://reviews.llvm.org/D10707
llvm-svn: 243419
Prior to CMAKE 2.8.4 that was covered by the WIN32 conditional but
from 2.8.4 CMAKE no longer defined WIN32 when running under Cygwin
and it needs its own test.
Patch by Martell Malone!
http://reviews.llvm.org/D11347
llvm-svn: 242993
One part of my refactoring from r242705 is untenable due to how CMake caches variables. There is no way other than caching to allow variables to be set in one directory and globally readable, but we really don't want to cache the temporary value marking that a directory has already been included.
llvm-svn: 242793
Summary:
When calling llgo-go from the llvm_add_go_executable
cmake function, specify $GO_EXECUTABLE as the go
command to call. Without this, llgo-go searches $PATH
which may be inconsistent with $GO_EXECUTABLE.
Reviewers: pcc
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D11290
llvm-svn: 242749
Re-landing r242059 which re-landed r241621... I'm really bad at this.
Summary (r242059):
This change re-lands r241621, with an additional fix that was required to allow tool sources to live outside the llvm checkout. It also no longer renames LLVM_EXTERNAL_*_SOURCE_DIR. This change was reverted in r241663, because it renamed several variables of the format LLVM_EXTERNAL_*_* to LLVM_TOOL_*_*.
Summary (r241621):
The tools CMakeLists file already had implicit tool registration, but there were a few things off about it that needed to be altered to make it work. This change addresses all that. The changes in this patch are:
* factored out canonicalizing tool names from paths to CMake variables * removed the LLVM_IMPLICIT_PROJECT_IGNORE mechanism in favor of LLVM_EXTERNAL_${nameUPPER}_BUILD which I renamed to LLVM_TOOL_${nameUPPER}_BUILD because it applies to internal and external tools
* removed ignore_llvm_tool_subdirectory() in favor of just setting LLVM_TOOL_${nameUPPER}_BUILD to Off
* Added create_llvm_tool_options() to resolve a bug in add_llvm_external_project() - the old LLVM_EXTERNAL_${nameUPPER}_BUILD would not work on a clean CMake directory because the option could be created after it was set in code.
* Removed all but the minimum required calls to add_llvm_external_project from tools/CMakeLists.txt
Differential Revision: http://reviews.llvm.org/D10665
llvm-svn: 242705
LLVM_EXTERNAL_*_SOURCE_DIR is reset as PATH with set(CACHE PATH).
Then the CACHE PATH variable, LLVM_EXTERNAL_*_SOURCE_DIR, is normalized as
${CMAKE_SOURCE_DIR}/${path_var} if ${path_var} is relative.
llvm-svn: 242120
add_llvm_external_project puts LLVM_EXTERNAL_${nameUPPER}_SOURCE_DIR into the cache even if it is just the in-tree default path. This causes all sorts of oddness, and makes it so that I can't change the behavior of this variable.
This patch never puts LLVM_EXTERNAL_${nameUPPER}_SOURCE_DIR into the cache. It will only end up in the cache if it is specified on the command line, which is the correct behavior.
There is also a temporary change to remove non-default values from the cache if they are already present. This should have the impact of cleaning out unncecissary values from the caches on the buildbots and people's local build directories. This part of the change is marked with a TODO and can be removed in a few days.
llvm-svn: 242102
Summary:
This change re-lands r241621, with an additional fix that was required to allow tool sources to live outside the llvm checkout. It also no longer renames LLVM_EXTERNAL_*_SOURCE_DIR. This change was reverted in r241663, because it renamed several variables of the format LLVM_EXTERNAL_*_* to LLVM_TOOL_*_*.
Original Summary:
The tools CMakeLists file already had implicit tool registration, but there were a few things off about it that needed to be altered to make it work. This change addresses all that. The changes in this patch are:
* factored out canonicalizing tool names from paths to CMake variables * removed the LLVM_IMPLICIT_PROJECT_IGNORE mechanism in favor of LLVM_EXTERNAL_${nameUPPER}_BUILD which I renamed to LLVM_TOOL_${nameUPPER}_BUILD because it applies to internal and external tools
* removed ignore_llvm_tool_subdirectory() in favor of just setting LLVM_TOOL_${nameUPPER}_BUILD to Off
* Added create_llvm_tool_options() to resolve a bug in add_llvm_external_project() - the old LLVM_EXTERNAL_${nameUPPER}_BUILD would not work on a clean CMake directory because the option could be created after it was set in code.
* Removed all but the minimum required calls to add_llvm_external_project from tools/CMakeLists.txt
Differential Revision: http://reviews.llvm.org/D10665
llvm-svn: 242059
Summary:
The tools CMakeLists file already had implicit tool registration, but there were a few things off about it that needed to be altered to make it work. This change addresses all that. The changes in this patch are:
* factored out canonicalizing tool names from paths to CMake variables
* removed the LLVM_IMPLICIT_PROJECT_IGNORE mechanism in favor of LLVM_EXTERNAL_${nameUPPER}_BUILD which I renamed to LLVM_TOOL_${nameUPPER}_BUILD because it applies to internal and external tools
* removed ignore_llvm_tool_subdirectory() in favor of just setting LLVM_TOOL_${nameUPPER}_BUILD to Off
* Added create_llvm_tool_options() to resolve a bug in add_llvm_external_project() - the old LLVM_EXTERNAL_${nameUPPER}_BUILD would not work on a clean CMake directory because the option could be created after it was set in code.
* Removed all but the minimum required calls to add_llvm_external_project from tools/CMakeLists.txt
Reviewers: bogner, samsonov, chapuni, beanz
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D10665
llvm-svn: 241621
This patch changes linkage with dbghlp.dll for clang from static (at load time)
to on demand (at the first use of required functions). Clang uses dbghlp.dll
only in minor use-cases. First of all in case of crash and in case of plugin load.
The dbghlp.dll library can be absent on system. In this case clang will fail
to load. With lazy load of dbghlp.dll clang can work even if dbghlp.dll
is not available.
Differential Revision: http://reviews.llvm.org/D10737
llvm-svn: 241271
generated by the Autoconf/Makefile build system relocatable.
Previously the generated CMake files contained hardcoded paths which
prevented a binary installation from being relocated to a different
place in the file system. This problem was most noticeable in LLVM's
official binary releases which were completely unusable by a downstream
project trying to import the CMake targets.
Package maintainers who choose to modify the install location of the
CMake directory without using the ``PROJ_cmake`` Makefile variable
override will need to patch the generated``LLVMConfig.cmake`` so that
``LLVM_INSTALL_PREFIX`` and ``_LLVM_CMAKE_DIR`` variables are set
correctly.
llvm-svn: 241080
CMake files and should not be by both build systems and also the targets
were also installed by the CMake build system which they should not be.
The problem was that
- the CMake build of LLVM installs and exports the gtest library
targets. We should not being doing this, these are not part of LLVM.
- the Autoconf/Makefile build of LLVM still had gtest libraries in the
installed LLVMConfig.cmake.
These problems would cause problems for an external project because when
calling llvm_map_components_to_libnames(XXX all) ${XXX} would to contain
LLVM's internal gtest libraries.
llvm-svn: 240981
ctypes 0.3 and earlier contains an interface-definig bug:
its ptr_of_raw_address accepts Int64 and not Nativeint. ctypes 0.4
was not released during the 3.6 cycle, and because of that, LLVM 3.6
was released with ctypes 0.3 as a dependency, which now breaks
the build on modern ctypes.
Unbreak.
llvm-svn: 240882
Summary:
Finally, delete LLVM's parse_arguments() definition.
Second part of D10531.
This is dependent on http://reviews.llvm.org/D10529
Reviewers: pcc, beanz, chapuni
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D10531
llvm-svn: 240122
The cmake check for whether libatomic could be used had been
unconditionally setting the result to false. Which was somewhat
fortunate, because the prerequisite check for whether it was *needed*
was always claiming it was, even if it was not.
However, this made platforms where libatomic is actually necessary
fail to link.
Differential Revision: http://reviews.llvm.org/D10453
llvm-svn: 239819
- Who defines ${LLVM_SOURCE_DIR} ?
- Would windows_version_resource.rc be available in an *installed* llvm tree?
I suggest it may be installed in ${PREFIX}/share.
llvm-svn: 239703
This reinstates my commits r238740/r238741 which I reverted due to a failure
in the clang-cl selfhost tests on Windows. I've now fixed the issue in
clang-cl that caused the failure so hopefully all should be well now.
llvm-svn: 239612
OCaml doc builds fail without .cmi files, and .cmi files are collected
in ocaml_outputs. Therefore, make doc targets depend on ocaml_outputs as
well.
Fixes: https://llvm.org/bugs/show_bug.cgi?id=23777
Patch by Michał Górny <mgorny@gentoo.org>
llvm-svn: 239259
This embeds Windows version information into our executables and DLLs.
The most visible place to view this data is in the details tab of the file
properties window in Windows explorer.
Differential Revision: http://reviews.llvm.org/D7828
llvm-svn: 238740
Summary: Multi-configuration builds put their binaries into ${CMAKE_BINARY_DIR}/Release/bin/. The table-gen cross-compilation support needs to take that into account.
Reviewers: yaron.keren
Reviewed By: yaron.keren
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D10102
llvm-svn: 238592
I can't actually test this properly because uninstalling MSVC 2015 CTP 6
and reinstalling the 2015 RC takes hours. I can only verify that this
doesn't mess up MSVC 2013 and 2015 CTP 6 builds, which is what I've
done.
Should fix PR23513.
llvm-svn: 237743
The gold binary is not required to build the plugin. All that is
needed is for LLVM_BINUTILS_INCDIR to point to the directory
containing plugin-api.h.
llvm-svn: 235918
In CMake dependencies can be filenames or targets, and targets can't be filenames. The Ninja generator handles filename dependencies because it generates targets for every output file from a command. For example:
add_custom_command(OUTPUT foo.txt COMMAND touch foo.txt)
With the Ninja generator this generates a target foo.txt, but with the Makefile generator it doesn't. This is probably because Ninja explicitly requires these hard dependency ties, and Make just behaves oddly in general.
To fix this we need to make the tablegen actions depend on a target rather than a filename.
llvm-svn: 235732
This adds the following targets to cmake. These can be used to build and link only specific parts of a backend, instead of having to link the whole backend.
- AllTargetsAsmPrinters, AllTargetsAsmParsers, AllTargetsDescs, AllTargetsDisassemblers, AllTargetsInfos
A typical use for these is instead of linking ${LLVM_TARGETS_TO_BUILD}. This commit changes llvm-mc to show how to use the new targets.
Reviewed by Chris Bieneman.
llvm-svn: 235324
The CMake install command is defined as:
install(TARGETS targets... [EXPORT <export-name>]
[[ARCHIVE|LIBRARY|RUNTIME|FRAMEWORK|BUNDLE|
PRIVATE_HEADER|PUBLIC_HEADER|RESOURCE]
[DESTINATION <dir>]
[INCLUDES DESTINATION [<dir> ...]]
[PERMISSIONS permissions...]
[CONFIGURATIONS [Debug|Release|...]]
[COMPONENT <component>]
[OPTIONAL] [NAMELINK_ONLY|NAMELINK_SKIP]
] [...])
This means it can only take one parameter from the set of RUNTIME, LIBRARY, or ARCHIVE. If you set more than one of these it seems to gobble up the extra arguments and ignore the COMPONENT argument.
This adds a check to only set LIBRARY or ARCHIVE based on whether or not the library being built is shared.
llvm-svn: 235113
Certain versions of CMake specify /W3 as part of CMAKE_CXX_FLAGS
by default, before you do anything. Appending /W4 to the end of
this and using the Ninja generator results in
cl : Command line warning D9025 : overriding '/W3' with '/W4'.
It is not possible to suppress this since it is a command line
warning and not a compiler warning, so we must fix the command
line to contain only one value for /Wn.
llvm-svn: 234907
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.
llvm-svn: 234159
Added a new boolean CMake flag, LLVM_INSTALL_UTILS. When set,
the 'install' target will include in the bin directory the
utils binaries - e.g. FileCheck. This mirrors the autoconfig
behavior.
Test Plan:
Locally verified that utils binaries are copied when flag is set,
and not copied when flag is not set.
Reviewers: jfb, dschuff, beanz
Reviewed By: beanz
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D8587
Patch by Mircea Trofin
llvm-svn: 233385
Summary:
This patch is an attempt at making `DenseMapIterator`s "fail-fast".
Fail-fast iterators that have been invalidated due to insertion into
the host `DenseMap` deterministically trip an assert (in debug mode)
on access, instead of non-deterministically hitting memory corruption
issues.
Enabling fail-fast iterators breaks the LLVM C++ ABI, so they are
predicated on `LLVM_ENABLE_ABI_BREAKING_CHECKS`.
`LLVM_ENABLE_ABI_BREAKING_CHECKS` by default flips with
`LLVM_ENABLE_ASSERTS`, but can be clamped to ON or OFF using the CMake /
autoconf build system.
Reviewers: chandlerc, dexonsmith, rnk, zturner
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D8351
llvm-svn: 233310
Summary:
This change makes CMake scan for lit suites and generate a target for each lit test suite. The targets follow the format check-<project>-<suite path>.
For example:
check-llvm-unit - Runs the LLVM unit tests
check-llvm-codegen-arm - Runs the ARM codeine tests
Note: These targets are not generated during multi-configuration generators (i.e. Xcode and Visual Studio) because target clutter impacts UI usability.
* Also fixed a minor issue that Duncan pointed out to me I was passing the suite to lit twice
Reviewers: chandlerc
Subscribers: aemerson, llvm-commits
Differential Revision: http://reviews.llvm.org/D8380
llvm-svn: 233009
This works in a similar way to the gold plugin tests. We search for a compatible
linker on $PATH and use it to run tests against our just-built libLTO. To start
with, test the just added opt level functionality.
Differential Revision: http://reviews.llvm.org/D8472
llvm-svn: 232785
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.
llvm-svn: 232730
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
llvm-svn: 232727
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
llvm-svn: 232671
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.
llvm-svn: 232662
* 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.
llvm-svn: 232067
* There is no reason to require SDKROOT as an environment variable because we can derive it from xcrun
* Setting CMAKE_RANLIB makes our static archives usable
llvm-svn: 232053
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
llvm-svn: 231924
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
llvm-svn: 231842
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.
llvm-svn: 231560
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.
llvm-svn: 231166
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.
llvm-svn: 230539
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!
llvm-svn: 230452
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.
llvm-svn: 230343
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
llvm-svn: 230239
NOTE: This patch intentionally breaks the build. It attempts
to resubmit r230083, but with some debug logging in the CMake
and lit config files to determine why certain bots do not
correctly disable the DIA tests when DIA is not available.
After a sufficient number of bots fail, this patch will either
be reverted or, if the cause of the failure becomes obvious,
a fix submitted with the log statements removed.
llvm-svn: 230161
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
llvm-svn: 229727
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!
llvm-svn: 229584
a gold binary explicitly. Substitute this binary into the tests rather
than just directly executing the 'ld' binary.
This should allow folks to inject a cross compiling gold binary, or in
my case to use a gold binary built and installed somewhere other than
/usr/bin/ld. It should also allow the tests to find 'ld.gold' so that
things work even if gold isn't the default on the system.
I've only stubbed out support in the makefile to preserve the existing
behavior with none of the fancy logic. If someone else wants to add
logic here, they're welcome to do so.
llvm-svn: 229251
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
llvm-svn: 228670
This allows all CMake projects, as well as C++ code, to detect if
and when DIA SDK is available for use so that we can enable the
DIA-based PDB reader implementation.
Differential Revision: http://reviews.llvm.org/D7457
Reviewed By: Chandler Carruth
llvm-svn: 228669
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
llvm-svn: 228219
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
llvm-svn: 228049
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
llvm-svn: 227216
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.
llvm-svn: 226611
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.
llvm-svn: 225778
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).
llvm-svn: 225321
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
llvm-svn: 224962
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.
llvm-svn: 224920
*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.
llvm-svn: 224919
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.
llvm-svn: 224554
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.
llvm-svn: 223425
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.
llvm-svn: 223139
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.
llvm-svn: 222391
Summary: This will help in testing libc++ and libc++abi with tsan.
Reviewers: samsonov
Reviewed By: samsonov
Subscribers: samsonov, llvm-commits
Differential Revision: http://reviews.llvm.org/D6283
llvm-svn: 222258
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.
llvm-svn: 221530
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.
llvm-svn: 221012
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
llvm-svn: 220935
On FreeBSD 10.0, size_t needs to be defined before including cxxabi.h.
Currenty HAVE_CXXABI_H is not defined on FreeBSD because of that reason.
This patch teaches cmake and configure how to include it.
http://reviews.llvm.org/D5940
llvm-svn: 220665
This tool lets us build LLVM components within the tree by setting up a
$GOPATH that resembles a tree fetched in the normal way with "go get".
It is intended that components such as the Go frontend will be built in-tree
using this tool.
Differential Revision: http://reviews.llvm.org/D5902
llvm-svn: 220462
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
llvm-svn: 220410
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.
llvm-svn: 220252
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.
llvm-svn: 220198
This code is based on the existing LLVM Go bindings project hosted at:
https://github.com/go-llvm/llvm
Note that all contributors to the gollvm project have agreed to relicense
their changes under the LLVM license and submit them to the LLVM project.
Differential Revision: http://reviews.llvm.org/D5684
llvm-svn: 219976
In fact, symbolization is now expected to work only on Linux and
FreeBSD/NetBSD, where we have dl_iterate_phdr and can learn the
main executable name without argv0 (it will be possible on BSD systems
after http://reviews.llvm.org/D5693 lands). #ifdef-out the code for
all the rest Unix systems.
Reviewed in http://reviews.llvm.org/D5610
llvm-svn: 219534
This change modifies fatal signal handler used in LLVM tools.
Now it attempts to find llvm-symbolizer binary and communicates
with it in order to turn instruction addresses into
function/file/line info entries. This should significantly improve
stack traces readability in Debug builds.
This feature only works on selected platforms (including Darwin
and Linux). If the symbolization fails for some reason, signal
handler will fallback to the original behavior.
Reviewed in http://reviews.llvm.org/D5610
llvm-svn: 219354
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.
llvm-svn: 218542
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.
llvm-svn: 217484
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.
llvm-svn: 217105
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
llvm-svn: 216328
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.
llvm-svn: 216327
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.
llvm-svn: 214078
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.
llvm-svn: 213663
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.
llvm-svn: 213099
This adds support for building native artifacts when cross-compiling using the
popular side-by-side source directory layout (no symlinks, no nested
repositories).
llvm-svn: 213091
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.
llvm-svn: 212934
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.
llvm-svn: 212590
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.
llvm-svn: 212587
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
llvm-svn: 212586
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.
llvm-svn: 212315
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!
llvm-svn: 211919
clang's own CMake setup handles this as of r210308.
The CMAKE_CROSSCOMPILING special-case will no longer be hard-coded. This was
clearly site-specific to someone's local configuration and should be passed in
at configure time if needed with e.g. -DLIBXML2_LIBRARIES=... (the libxml2
target I tried here doesn't even support liblzma so it's *way* off).
llvm-svn: 210309
Replace the crufty build-time configure checks for program paths with
equivalent runtime logic.
This lets users install graphing tools as needed without having to reconfigure
and rebuild LLVM, while eliminating a long chain of inappropriate compile
dependencies that included GUI programs and the windowing system.
Additional features:
* Support the OS X 'open' command to view graphs generated by any of the
Graphviz utilities. This is an alternative to the Graphviz OS X UI which is
no longer available on Mountain Lion.
* Produce informative log output upon failure to indicate which programs can
be installed to view graphs.
Ping me if this doesn't work for your particular environment.
llvm-svn: 210001
This commit starts with a "git mv ARM64 AArch64" and continues out
from there, renaming the C++ classes, intrinsics, and other
target-local objects for consistency.
"ARM64" test directories are also moved, and tests that began their
life in ARM64 use an arm64 triple, those from AArch64 use an aarch64
triple. Both should be equivalent though.
This finishes the AArch64 merge, and everyone should feel free to
continue committing as normal now.
llvm-svn: 209577
abort while configuring if doxygen could not be found. This
is desirable because if the build is going to fail then it should
fail as early as possible.
llvm-svn: 207404
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>!
llvm-svn: 206655
This adds a second implementation of the AArch64 architecture to LLVM,
accessible in parallel via the "arm64" triple. The plan over the
coming weeks & months is to merge the two into a single backend,
during which time thorough code review should naturally occur.
Everything will be easier with the target in-tree though, hence this
commit.
llvm-svn: 205090
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
llvm-svn: 203792
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.
llvm-svn: 203760
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
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.
llvm-svn: 201969
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.
llvm-svn: 201854
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.
llvm-svn: 201853
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.
llvm-svn: 201852
On unsupported platforms, llvm_add_library(MODULE) doesn't create any targets.
Caller may be responsible to check and add extra target properties.
llvm-svn: 201320
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.
llvm-svn: 201316
I was insightless then about unknown optional parameters.
(Consider that LINK_LIBS foo bar ADDITIONAL_HEADERS qux quux)
Suggested by Michael Kruse. Thanks!
llvm-svn: 201283
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.
llvm-svn: 201229
- 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.
llvm-svn: 201072
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.
llvm-svn: 201063
CMake's target_link_libraries() will manage dependencies with Brad's LLVMConfig improvements.
Configuration time may be reduced by a few seconds.
llvm-svn: 201062
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.
llvm-svn: 201053
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.
llvm-svn: 201051
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.
llvm-svn: 201050
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.
llvm-svn: 201049
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.
llvm-svn: 201048
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.
llvm-svn: 201047
ISSUE:
On Ubuntu 12.04 LTS, arc4random is provided by libbsd.so, which is a
transitive dependency of libedit. If a system had libedit on it that
was implemented in terms of libbsd.so, then the arc4random test,
previously implemented as a linker test, would succeed with -ledit.
However, on Ubuntu this would also require a #include <bsd/stdlib.h>.
This caused a build breakage on configure-based Ubuntu 12.04 with
libedit installed.
FIX:
This fix changes configure to test for arc4random by searching for it
in the standard header files. On Ubuntu 12.04, this test now properly
fails to find arc4random as it is not defined in the default header
locations. It also tweaks the #define names to match the output of the
header check command, which is slightly different than the linker
function check #defines.
I tested the following scenarios:
(1) Ubuntu 12.04 without the libedit package [did not find arc4random,
as expected]
(2) Ubuntu 12.04 with libedit package [properly did not find
arc4random, as expected]
(3) Ubuntu 12.04 with most recent libedit, custom built, and not
dependent on libbsd.so [properly did not find arc4random, as
expected].
(4) FreeBSD 10.0B1 [properly found arc4random, as expected]
llvm-svn: 200819
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.
llvm-svn: 200812
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.
llvm-svn: 200811
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. ;)
llvm-svn: 200762
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.
llvm-svn: 200744
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.
llvm-svn: 200730
This library will be used by clang-query. I can imagine LLDB becoming another
client of this library, so I think LLVM is a sensible place for it to live.
It wraps libedit, and adds tab completion support.
The code is loosely based on the line editor bits in LLDB, with a few
improvements:
- Polymorphism for retrieving the list of tab completions, based on
the concept pattern from the new pass manager.
- Tab completion doesn't corrupt terminal output if the input covers
multiple lines. Unfortunately this can only be done in a truly horrible
way, as far as I can tell. But since the alternative is to implement our
own line editor (which I don't think LLVM should be in the business of
doing, at least for now) I think it may be acceptable.
- Includes a fallback for the case where the user doesn't have libedit
installed.
Note that this uses C stdio, mainly because libedit also uses C stdio.
Differential Revision: http://llvm-reviews.chandlerc.com/D2200
llvm-svn: 200595
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.
llvm-svn: 200301
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.
llvm-svn: 200299
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
)
llvm-svn: 199639
In LLVM build tree, they points corresponding INTDIR.
In Clang standalone tree, they points external dir (llvm-config's --bindir and --libdir).
llvm-svn: 199595
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.
llvm-svn: 199484
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!
llvm-svn: 199356
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.
llvm-svn: 199149
likely to be reverted and re-applied a few times. The minimum versions
we're aiming at:
GCC 4.7
Clang 3.1
MSVC 17.0 (Visual Studio 2012)
Let me know if something breaks!
llvm-svn: 199145
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.
llvm-svn: 198746
Summary:
This parameter is required to build C++11 projects (like lld or lldb) on OS X as the default STL does not provide c++ classes.
CC: llvm-commits, triton
Differential Revision: http://llvm-reviews.chandlerc.com/D2381
llvm-svn: 198625
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.
llvm-svn: 198344
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
John Brawn