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
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]
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200819 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
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200595 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
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!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199145 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
add_public_tablegen_target adds *CommonTableGen to LLVM_COMMON_DEPENDS.
LLVM_COMMON_DEPENDS affects add_llvm_library (and other add_target stuff) within its scope.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195927 91177308-0d34-0410-b5e6-96231b3b80d8
In some case, it may be required to build LLVM in C++11 mode, as some the subprojects (like lldb) requires it.
This mimics the autoconf behaviour.
However, given the discussions on the switch to C++11 of the codebase, this behaviour should evolve to default to C++11 with some checks of the compiler capabilities.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195727 91177308-0d34-0410-b5e6-96231b3b80d8
for release builds.
This is a follow-up to r194589. Aaron pointed out that building
libraries with /MT and using them in an application that uses a
different run-time library can be a bad idea.
Move the option to build with /MT behind a CMake option so it can be
turned on selectively, such as when building the toolchain installer.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194596 91177308-0d34-0410-b5e6-96231b3b80d8
After r192904, Reid pointed out he thought we already set the stack
size for MSVC. Turns out we did, but it didn't seem to work.
This commit sets the stack size in a single place, using
CMAKE_EXE_LINKER_FLAGS because that seems to be the way that works
best.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@192912 91177308-0d34-0410-b5e6-96231b3b80d8
Compiling under Visual C++ 2012 with the default stack size of 1MB, the stack
overflows at a depth of 216 template instantiations, well before the 256
default limit. This patch modifies the default MSVC stack size to 2MB.
Patch by Yaron Keren!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@192904 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
The MSVCRT deliberately sends main() code-page specific characters.
This isn't too useful to LLVM as we end up converting the arguments to
UTF-16 and subsequently attempt to use the result as, for example, a
file name. Instead, we need to have the ability to access the Unicode
command line and transform it to UTF-8.
This has the distinct advantage over using the MSVC-specific wmain()
function as our entry point because:
- It doesn't work on cygwin.
- It only work on MinGW with caveats and only then on certain versions.
- We get to keep our entry point as main(). :)
N.B. This patch includes fixes to other parts of lib/Support/Windows
s.t. we would be able to take advantage of getting the Unicode paths.
E.G. clang spawning clang -cc1 would want to give it Unicode arguments.
Reviewers: aaron.ballman, Bigcheese, rnk, ruiu
Reviewed By: rnk
CC: llvm-commits, ygao
Differential Revision: http://llvm-reviews.chandlerc.com/D1834
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@192069 91177308-0d34-0410-b5e6-96231b3b80d8
I got a report of a hang in git's helper functions trying to figure out
how to display results of "git svn info" when run inside ninja, even though
the result is immediately piped to grep. This seems to avoid that.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@190808 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 changes the interface of GetSVN.cmake. Clang change to follow.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@190556 91177308-0d34-0410-b5e6-96231b3b80d8
