LLVM_ENABLE_CXX1Y (default *off*). =D C++98 is dead. Long live C++11.

I don't exactly recommend using C++1y just yet though...

llvm-svn: 202567

Patch by Jevin Sweval!

llvm-svn: 202556

Now, please don't get too excited. I've just toggled the default to suss
out the last remaining bot problems. This does *not* mean we can all go
write lots of C++11 code yet. I at least want to let the dust settle
from the bots first.

llvm-svn: 202542

This centralizes the Makefile handling of -install_name and -rpath. It also
moves the cmake build to using @rpath. The reason being that libclang needs it,
and it works for everything else.

A followup patch will move clang to using this and then there will be a single
point to edit to support other systems.

llvm-svn: 202499

llvm-svn: 202363

Using @executable_path/../lib matches what we have on Makefiles and works
with older versions of OS X too.

llvm-svn: 202302

For now, use both keywords, INTERFACE and PRIVATE via the variable,
  - ${cmake_2_8_12_INTERFACE}
  - ${cmake_2_8_12_PRIVATE}

They could be cleaned up when we introduce 2.8.12.

llvm-svn: 202239

Commit 201921 overrides setting of CMAKE_INSTALL_RPATH via the
command line. Last time this happened we applied another patch
to only set CMAKE_INSTALL_RPATH if already defined (r197825).
This patch does the same thing again, but only for the UNIX
case - we leave APPLE alone as presumably the original committer
is happy with the non-overriding behaviour.

llvm-svn: 202085

This reverts commit r201934.

Polly has been fixed to work with this.

llvm-svn: 201936

This reverts commit r201921.

This should bring the polly bots back. I will try to build it locally to
understand how cmake was setting the rpath of LLVMPolly.so.

llvm-svn: 201934

This works by asking cmake to use the "install rpath", but setting that rpath
to be relative.

Thanks a lot to Brad King for the help with CMake!

llvm-svn: 201921

The CMake install(DIRECTORY) command documents that it sets permissions
on directories it is asked to install.  Since the <prefix>/include
directory may not be exclusive to the LLVM installation, we should not
ask CMake to manage permissions of that directory for us.  Instead, give
only our own include/llvm and include/llvm-c subdirectories to the
install(DIRECTORY) command.

Fixes PR4500. Patch by Brad King.

llvm-svn: 201075

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

Suggested by Stephen Kelly.

llvm-svn: 200645

llvm-svn: 200558

  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

llvm-svn: 199594

llvm-svn: 199593

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

compiler version checking doesn't work on 2.8.7. This feature was
documented in 2.8.10, but existed for an unknown amount of time before
that.

I'm actually happy to revert this and remove the use of the feature if
there is anyone with a specific problem updating CMake. Please just let
me know. I don't want to re-implement this CMake functionality unless
there is a reason, and this is the only real way to find that out.

llvm-svn: 199148

It was too late to set BUG_REPORT_URL after configure_file(config.h).
BUG_REPORT_URL in config.h.cmake would be updated at 2nd run of cmake.
It caused many recompilations.

FYI, configure handles BUG_REPORT_URL in llvm side.

llvm-svn: 199076

Introduce a cmake LLVM_ENABLE_LIBCXX build parameter to compile using libc++ instead of the system default 

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

[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: 197825

This matches what the configure build does.

Patch by Jan Vesely.

Fixes pr14189.

llvm-svn: 197743

[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

llvm-svn: 197392

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

- Allow overriding PACKAGE_VERSION from the command-line
- Use PACKAGE_VERSION to set CPACK_PACKAGE_VERSION (used by the Win installer)
- Don't include the version number in the CPack install dir or registry key.

Differential revision: http://llvm-reviews.chandlerc.com/D2245

llvm-svn: 195379

llvm-svn: 195247

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

llvm-svn: 193813

llvm-svn: 193541

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

Restore LLVM_BUILD_RUNTIME option that was deleted in r191835, but is still used to control building of compiler-rt and libcxx

llvm-svn: 191948

infrastructure.

This was essentially work toward PGO based on a design that had several
flaws, partially dating from a time when LLVM had a different
architecture, and with an effort to modernize it abandoned without being
completed. Since then, it has bitrotted for several years further. The
result is nearly unusable, and isn't helping any of the modern PGO
efforts. Instead, it is getting in the way, adding confusion about PGO
in LLVM and distracting everyone with maintenance on essentially dead
code. Removing it paves the way for modern efforts around PGO.

Among other effects, this removes the last of the runtime libraries from
LLVM. Those are being developed in the separate 'compiler-rt' project
now, with somewhat different licensing specifically more approriate for
runtimes.

llvm-svn: 191835

This makes sure we get the same behavior with all supported cmake versions. Once
we support only versions >= 2.8.11 we can experiment with other values or just
setting it for some binaries.

Patch by Greg Bedwell.

llvm-svn: 191372

 - We do some nasty things w.r.t. installing or overriding signal handlers in
   order to improve our crash recovery support or interaction with crash
   reporting software, and those things are not necessarily appropriate when
   LLVM is being linked into a client application that has its own ideas about
   how to do things. This gives those clients a way to disable that handling at
   build time.

 - Currently, the code this guards is all Apple specific, but other platforms
   might have the same concerns so I went for a more generic configure
   name. Someone who is more familiar with library embedding on Windows can
   handle choosing which of the Windows/Signals.inc behaviors might make sense
   to go under this flag.

 - This also fixes the proper autoconf'ing of ENABLE_BACKTRACES. The code
   expects it to be undefined when disabled, but the autoconf check was just
   defining it to 0.

llvm-svn: 189694