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
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
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
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
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
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
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
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
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.
llvm-svn: 198151
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.
llvm-svn: 198140
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.
llvm-svn: 198136
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.
llvm-svn: 197590
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.
llvm-svn: 195929
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.
llvm-svn: 195927
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.
llvm-svn: 195727
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.
llvm-svn: 194596
This should fix the problem of snapshot builds created with MSVC 2012 not
working for users with MSVC 2010, etc.
Differential Revision: http://llvm-reviews.chandlerc.com/D2157
llvm-svn: 194589
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.
llvm-svn: 192912
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!
llvm-svn: 192904
