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
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
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
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
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
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
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
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
The issue is that CMAKE_BUILD_TYPE=RelWithDebInfo LLVM_ENABLE_ASSERTIONS=ON was
not building with assertions enabled. (I was unable to find what in the LLVM
source tree was adding -DNDEBUG to the build line in this case, so decided that
it must be cmake itself that was adding it - this may depend on the cmake
version). The fix treats any mode that is not Debug as being the same as
Release for this purpose (previously it was being assumed that cmake would only
add -DNDEBUG for Release and not for RelWithDebInfo or MinSizeRel). If other
versions of cmake don't add -DNDEBUG for RelWithDebInfo then that's OK: with
this change you just get a useless but harmless -UNDEBUG or -DNDEBUG.
llvm-svn: 186499
to have them appear in the right order. Instead append all warnings explicitly
to the language flags. This was already the case for many warnings. Fixes the
issue of -Wno-maybe-uninitialized not being effective because -Wall was being
placed after it rather than before.
llvm-svn: 177866
Added support to the cmake build to turn off uninitialized use warnings
for gcc. This cleans the build up somewhat.
Used logic simpler than found in autoconf by making use of the fact that
although gcc won't complain about unsupported -Wno-* flags it *will*
complain about unsupported -W flags.
Reviewers: gribozavr, doug.gregor, chandlerc
llvm-svn: 174299
catches uses of an extremely minor and widely-available C++ extension (which
every C++ compiler I could find supports, but EDG and Clang reject in strict
mode).
The diagnosed code pattern looks like this:
struct X {
union {
struct {
int a;
int b;
} S;
};
};
llvm-svn: 174103
gcc produces false positives for empty braces so turning the warning off.
Instead, turning the warning on for clang so proper warnings aren't missed.
Reviewers: dblaikie, chandlerc
llvm-svn: 174073
For example,
cur) unittests/ADT/Release/ADTTests
new) unittests/ADT/ADTTests
RUNTIME_BUILD_MODE can be substituted to CMAKE_CFG_INTDIR.
With Make and Ninja, the tree is not built with multiple configurations.
Then, including the build type in target directory doesn't make sense.
See also "How can I build multiple modes without switching?"
http://www.cmake.org/Wiki/CMake_FAQ
CMAKE_CFG_INTDIR is set to "."
With multiple-configuration-aware build system, like Visual Studio, each unittest is built on appropriate directory, for example,
unittests/ADT/Release/ADTTests.exe
CMAKE_CFG_INTDIR is set to build system's variable, like "$(Configuration)" or "$(OutDir)".
Thus, "--param build_config" is also deprecated.
llvm-svn: 173616
This warning fires on:
Operator::~Operator() {
llvm_unreachable("should never destroy an Operator");
}
That seems like a false positive. I don't see any good way to silence
the warning here, so I'm disabling it.
llvm-svn: 173455
Adding CXX_SUPPORTS_COVERED_SWITCH_DEFAULT_FLAG
C_SUPPORTS_COVERED_SWITCH_DEFAULT_FLAG
This is to handle the wackiness on a Mac host where cmake detects:
CMAKE_CXX_COMPILER == "/usr/bin/c++"
CMAKE_C_COMPILER == "/usr/bin/gcc"
llvm-svn: 168577
This was previously only done for executables and shared libraries, but not
for modules. As modules are essentially shared libraries (that need to be
dlopened explicitly), threating them the same as shared libraries seems
reasonable. This fixes the LLVM_BUILD_32_BITS build of Polly.
Contributed by: Ondra Hosek <ondra.hosek@gmail.com>
llvm-svn: 158195
output. Peter Collingbourne also reports that it is showing up in
$(llvm-config --cflags).
Revert this for now since I don't know enough cmake to fix it properly.
This reverts commit 18efed7adc79c1970f307bb5b015d199012ba872.
llvm-svn: 156392
Clang builds. The detection logic for compilers that support the warning
isn't working. Rafael is going to investigate it, but didn't want people
to have to wade through build spam until then.
llvm-svn: 151649
Take #2. Don't piggyback on the existing config.build_mode. Instead,
define a new lit feature for each build feature we need (currently
just "asserts"). Teach both autoconf'd and cmake'd Makefiles to define
this feature within test/lit.site.cfg. This doesn't require any lit
harness changes and should be more robust across build systems.
llvm-svn: 133664
with the contents of CMAKE_C(XX)_FLAGS too, else `llvm-config
--c(xx)flags' doesn't tell the absolute truth.
This comes from PR9603 and is based on a patch by Ryuta Suzuki!
llvm-svn: 128727
library.
Installs tblgen (required by Clang).
Translates handling of user settings and platform-dependant options to
its own file, where it can included by another project.
Installs the .cmake files required by projects like Clang.
llvm-svn: 124816
Chandler Carruth