When building Clang separately from LLVM with CMake, one should set
the path of llvm-config via the cache variable LLVM_CONFIG.

llvm-svn: 198316

[CMake][VS][XCode] Restruct the output directory layout more comfortable, ${BINARY_DIR}/${BUILD_MODE}/(bin|lib)

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

 

llvm-svn: 198203

llvm-svn: 198198

Also add leading spaces to the LINK_FLAGS setters, since that's what the cmake
folks recommend: http://www.cmake.org/pipermail/cmake/2012-October/052399.html

llvm-svn: 198182

llvm-svn: 198169

llvm-svn: 198166

Thanks to Edward-san, to let me know.

llvm-svn: 198165

llvm-svn: 198164

[CMake] add_llvm_symbol_exports: Use ${native_export_file} instead of equivalent constant "symbol.*', since it is defined.

llvm-svn: 198163

llvm-svn: 198159

r198153 fixed the msvs bot problem, but broke a msysgit bot. This change
hopefully makes both variants happy.

llvm-svn: 198156

Inspired by http://public.kitware.com/pipermail/cmake-developers/2012-March/003768.html

llvm-svn: 198153

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

llvm-svn: 198148

The current quoting is stripped by cmake, try quoting more.

llvm-svn: 198143

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

llvm-svn: 198139

`type` can't read from stdin.

llvm-svn: 198138

$ needs to be written $$ in makefiles, but not in cmakefiles.

llvm-svn: 198137

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

llvm-svn: 198135

llvm-svn: 197757

llvm-svn: 197703

llvm-svn: 197682

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

llvm-svn: 197581

llvm-svn: 197396

[CMake] Introduce LLVM_RUNTIME_OUTPUT_INTDIR and LLVM_LIBRARY_OUTPUT_INTDIR to reduce references to CMAKE_CFG_INTDIR.

Each of them forms like;
  ${CMAKE_BINARY_DIR}/bin/${CMAKE_CFG_INTDIR}
  ${CMAKE_BINARY_DIR}/lib/${CMAKE_CFG_INTDIR}

llvm-svn: 197394

[CMake] add_lit_target: Let lit.site.cfg free from "--param build_mode" on single configuration builds, like autoconf build.

llvm-svn: 196377

llvm-svn: 196093

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

Reid pointed out we already have LLVM_USE_CRT_{buildtype} to set it.

llvm-svn: 194604

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

llvm-svn: 193031

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