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
It was removed in r189130, but it turns out this makes life hard for
folks packaging LLVM and Clang and building the latter based on the
LLVM package.
Note that this only adds back the LLVM tblgen, and it's obviously
not included when LLVM_INSTALL_TOOLCHAIN_ONLY is set.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@190419 91177308-0d34-0410-b5e6-96231b3b80d8
LibXML2 config doesn't specify lzma as a dependency, which breaks
cross-compilation builds using new linkers (ld 2.21 or higher).
There is a bug on libxml2 to fix that, but since it's going to take
a while for things to go round and back, so we should have a harmless
addition of the library until then.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@190409 91177308-0d34-0410-b5e6-96231b3b80d8
Xcode always puts executable targets in the directory
bin/<Config>. When building separate LLVM and Clang projects for
Xcode, this prevents the CMake-configured project for Clang from
finding llvm-tblgen. Add a symlink so that tblgen executables are
always available in bin/ (regardless of the configuration LLVM is
built with).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189220 91177308-0d34-0410-b5e6-96231b3b80d8
Since it's an llvm-internal tool, we shouldn't install it.
(This depends on Clang r189127 and lld r189128.)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189130 91177308-0d34-0410-b5e6-96231b3b80d8
Allow CMake to pick up external projects in llvm/tools without the need to modify the "llvm/tools/CMakeLists.txt" file.
This makes it easier to work with projects that live in other repositories, without needing to specify each one in "llvm/tools/CMakeLists.txt".
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188921 91177308-0d34-0410-b5e6-96231b3b80d8
This tweaks the CMake rules for building an installation package on Windows:
- Sets license file (otherwise nsis shows an ugly default)
- Adds LLVM logo
- Shows "do you want to add this to the system path" dialog.
Differential Revision: http://llvm-reviews.chandlerc.com/D1414
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188509 91177308-0d34-0410-b5e6-96231b3b80d8
curses.h). Finding these headers is next to impossible. For example, on
Debian systems libtinfo-dev provides the terminfo reading library we
want, but *not* term.h. For the header, you have to use libncurses-dev.
And libncursesw-dev provides a *different* term.h in a different
location!
These headers aren't worth it. We want two functions the signatures of
which are clearly spec'ed in sys-v and other documentation. Just declare
them ourselves and call them. This should fix some debian builders and
provide better support for "minimal" debian systems that do want color
autodetection.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188165 91177308-0d34-0410-b5e6-96231b3b80d8
library for color support detection. This still will use a curses
library if that is all we have available on the system. This change
tries to use a smaller subset of the curses library, specifically the
subset that is on some systems split off into a separate library. For
example, if you install ncurses configured --with-tinfo, a 'libtinfo' is
install that provides just the terminfo querying functionality. That
library is now used instead of curses when it is available.
This happens to fix a build error on systems with that library because
when we tried to link ncurses into the binary, we didn't pull tinfo in
as well. =]
It should also provide an easy path for supporting the NetBSD
libterminfo library, but as I don't have access to a NetBSD system I'm
leaving adding that support to those folks.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188160 91177308-0d34-0410-b5e6-96231b3b80d8
LLVMConfig.cmake file that is (I think) used in the stand-alone Clang
build, and causing link errors there w.r.t. curses.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187950 91177308-0d34-0410-b5e6-96231b3b80d8
using it to detect whether or not a terminal supports colors. This
replaces a particularly egregious hack that merely compared the TERM
environment variable to "dumb". That doesn't really translate to
a reasonable experience for users that have actually ensured their
terminal's capabilities are accurately reflected.
This makes testing a terminal for color support somewhat more expensive,
but it is called very rarely anyways. The important fast path when the
output is being piped somewhere is already in place.
The global lock may seem excessive, but the spec for calling into curses
is *terrible*. The whole library is terrible, and I spent quite a bit of
time looking for a better way of doing this before convincing myself
that this was the fundamentally correct way to behave. The damage of the
curses library is very narrowly confined, and we continue to use raw
escape codes for actually manipulating the colors which is a much sane
system than directly using curses here (IMO).
If this causes trouble for folks, please let me know. I've tested it on
Linux and will watch the bots carefully. I've also worked to account for
the variances of curses interfaces that I could finde documentation for,
but that may not have been sufficient.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187874 91177308-0d34-0410-b5e6-96231b3b80d8
Previously this check was guarded by MSVC, which doesn't distinguish
between the compiler and the headers/library. This enables clang to
compile more of LLVM on Windows with Microsoft headers.
Remove some unused macros while I'm here: error_t and LTDL stuff.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187839 91177308-0d34-0410-b5e6-96231b3b80d8
On Windows, this improves clean cmake configuration time on my
workstation from 1m58s to 1m32s, which is pretty significant. There's
probably more that can be done here, but this is the low hanging fruit.
Eric volunteered to regenerate ./configure for me.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187209 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@186499 91177308-0d34-0410-b5e6-96231b3b80d8
This patch wires up the SystemZ target in configure, so that it can now be
built using --enable-targets=systemz. It is not yet included in the default
build (--enable-targets=all); this will be done by a follow-up patch.
Patch by Richard Sandiford.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@181208 91177308-0d34-0410-b5e6-96231b3b80d8
The intended semantics mirror autoconf, where the user is able to
specify a host triple, but if it's left to the build system then
"config.guess" is invoked for the default.
This also renames the LLVM_HOSTTRIPLE define to LLVM_HOST_TRIPLE to
fit in with the style of the surrounding defines.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@181112 91177308-0d34-0410-b5e6-96231b3b80d8
This makes llvm-dwarfdump and llvm-symbolizer understand
debug info sections compressed by ld.gold linker.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@180088 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@177866 91177308-0d34-0410-b5e6-96231b3b80d8
it. NetBSD/ARM and TILE-Gx are examples for platforms that have an
unusable fenv.h and this avoids the need for a blacklist.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@177865 91177308-0d34-0410-b5e6-96231b3b80d8
CMake and autotools disagree on what "host" means in a cross-compilation
context. Autotools (and lit) take it to be the machine the binaries being
compiled now will run on. CMake takes it to be the machine actually compiling
the binaries now.
This change makes lit.site-cfg more consistent between autotools and CMake,
allowing lit tests (particularly in ExecutionEngine) to run correctly when
cross-compiled with CMake
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@175179 91177308-0d34-0410-b5e6-96231b3b80d8
check_cxx_symbol_exists requires CMake 2.8.6, so even though I
recommended it to Owen it's probably better to stay away for now.
This check is not technically correct because we're checking <math.h>
but then using <cmath> in the actual code, but if we run into problems we
can do the same sort of dance as isinf() and isnan() where we check /both/
headers and then write a wrapper header around them.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@174773 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@174299 91177308-0d34-0410-b5e6-96231b3b80d8
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;
};
};
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@174103 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@174073 91177308-0d34-0410-b5e6-96231b3b80d8
