Always use list(APPEND) as it will perform the desired action even if the list
is empty or previously unset. The first set is harmless, however, the
subsequent set was overwriting the previous flag setup resulting in an improper
compilation command being generated. This manifested as a build failure on
Linux when using cmake + ninja.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@203638 91177308-0d34-0410-b5e6-96231b3b80d8
add_definitions is meant for adding C preprocessor definitions. Modern cmake
suggests use of the CMAKE_CXX_FLAGS for the purposes of pushing flags to the
compilation commands. Simply switch to the modern form given that we are
already requiring a new enough cmake.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@203637 91177308-0d34-0410-b5e6-96231b3b80d8
easier to use freshly-built clang with freshly-built libc++.
Basically, this makes it possible to run clang with libc++ without
having to install it, even if you don't have any version of libc++
installed in /usr/
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@194825 91177308-0d34-0410-b5e6-96231b3b80d8
Linking against libstdc++, rather than libsupc++, is probably better
for people who need to link against clients of libstdc++. Because
libsupc++ is provided only as a static library, its globals are not
shared between the static library and the copy linked into libstdc++.
This has been found to cause at least one test failure.
This also removes a number of symbols which were multiply defined
between libstdc++ and libc++, only when linking with libstdc++.
Differential Revision: http://llvm-reviews.chandlerc.com/D1825
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@192075 91177308-0d34-0410-b5e6-96231b3b80d8
I've changed it so we don't set highest level warnings (all) for MSVC when building projects using cmake and instead leave the default. That's /W4 on my machine and seems to be ok.
With all warnings on for msvc, we see literally thousands of warnings. 99.99% aren't relevant and just obscure the ones that are.
I think the user can still override things if they want something different from the command line when using cmake.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@192010 91177308-0d34-0410-b5e6-96231b3b80d8
libcxx doesn't build with -Werror because of #warnings in its source
code. But when libcxx is built as an external LLVM project, it inherits
LLVM build flags, breaking the build if LLVM_ENABLE_WERROR is enabled.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@191814 91177308-0d34-0410-b5e6-96231b3b80d8
Otherwise if libcxx is built as an LLVM external project (after r191624),
"include(config-ix)" will include config-ix.cmake from LLVM, not from libcxx,
which will result in misconfigured build tree.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@191657 91177308-0d34-0410-b5e6-96231b3b80d8
You can now configure from the command line using:
-DLIBCXX_CXX_ABI=libsupc++
-DLIBCXX_LIBSUPCXX_INCLUDE_PATHS="path;path
Also documents how to build on Linux.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@171316 91177308-0d34-0410-b5e6-96231b3b80d8
LLVM_ENABLE_ASSERTIONS instead of LIBCXX_ENABLE_ASSERTIONS when
figuring out what _DEBUG/NDEBUG defines to set. It also tries to test
the non-existent variable 'uppercase_CMAKE_BUILD_TYPE', which the top
level LLVM CMakeLists.txt sets up, but which the top level libc++
CMakeLists.txt currently does not. Changing the variable name tested
and creating the uppercase release name variable allows libc++ to
honor the LIBCXX_ENABLE_ASSERTIONS option correctly.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@161308 91177308-0d34-0410-b5e6-96231b3b80d8
