Using file(COPY FILE...) has several downsides. Since the file command
is only executed at configuration time, any changes to headers made
after the initial CMake execution are ignored. This can lead to subtle
errors since the just built Clang will be using stale libc++ headers.
Furthermore, since the headers are copied prior to executing the build
system, this may hide missing dependencies on libc++ from other LLVM
components.
This changes replaces the use of file(COPY FILE...) command with a
custom command and target which addresses all aforementioned issues and
matches the implementation already used by other LLVM components that
also install headers like Clang builtin headers.
Differential Revision: https://reviews.llvm.org/D44773
llvm-svn: 329544
When libcxx is built in tree for a host which requires libatomic, LLVM's
configuration steps will determine it is required and add it to
CMAKE_REQUIRED_LIBRARIES. When libcxx is later configured, it tests if it
has C++ atomics without libatomic. The test erroneously passes as libatomic
is already part of the set of required libraries.
In turn, a number of the atomic tests will fail as they require libatomic
but the test suite is configured not to use libatomic.
Address this by always dropping libatomic from the set of required libraries
before determining if LIBCXX_HAVE_CXX_ATOMICS_WITHOUT_LIB is true,
then restoring the set of required libraries.
Reviewers: EricWF
Differential Revision: https://reviews.llvm.org/D43509
llvm-svn: 329167
Previously, the install command for the cxxabi headers specified
the wrong component, and therefore they were not being included
in the install-cxx command.
This patch corrects the component name.
llvm-svn: 318989
Despite a strong CMake warning that this is an unsupported
libcxx build configuration, some bots still rely on being
able to check out lit and libcxx independently with no
LLVM sources, and then run lit against libcxx.
A previous patch broke that workflow, so this is making it work
again. Unfortunately, it breaks generation of the llvm-lit
script for libcxx, but we will just have to live with that until
a solution is found that allows libcxx to make more use of
llvm build pieces. libcxx can still run tests by using the
ninja check target, or by running lit.py directly against the
build tree or source tree.
Differential Revision: https://reviews.llvm.org/D38057
llvm-svn: 313763
After speaking with the libcxx owners, they agreed that this is
a bug in the bot that needs to be fixed by the bot owners, and
the CMake changes are correct.
llvm-svn: 313643
This reverts commit 4ad71811d45268d81b60f27e3b8b2bcbc23bd7b9.
There is a bot that is checking out libcxx and lit with nothing
else and then running lit.py against the test tree. Since there's
no LLVM source tree, there's no LLVM CMake. CMake actually
reports this as a warning saying unsupported libcxx configuration,
but I guess someone is depending on it anyway.
llvm-svn: 313607
This is going to be used by the runtime build in the multi-target
setup to allow using different install prefix for each target.
Differential Revision: https://reviews.llvm.org/D33762
llvm-svn: 307615
CMake has the problem with the single dash variant because of the
space, so use the double dash with equal sign version. We also
don't have to pass the target triple when checking for compiler-rt
since that flag is already included in compile flags now.
Differential Revision: https://reviews.llvm.org/D32068
llvm-svn: 300409
When compiler-rt is requested, we should attempt to link compiler-rt
builtins library rather than gcc_s.
Differential Revision: https://reviews.llvm.org/D31617
llvm-svn: 299599
Clang doesn't produce gcov compatible coverage files. This
causes lcov to break because it uses gcov by default. This
patch switches lcov to use llvm-cov as the gcov-tool.
Unfortunatly llvm-cov doesn't provide a gcov like interface by
default so it won't work with lcov. However `llvm-cov gcov` does.
For this reason we generate 'llvm-cov-wrapper' script that always
passes the gcov flag.
llvm-svn: 297553
This recommits r294707 with additional fixes. The main difference is
libc++ now correctly builds without any ABI library.
exception.cpp is a bloody mess. It's full of confusing #ifdef branches for
each different ABI library we support, and it's getting unmaintainable.
This patch breaks down exception.cpp into multiple different header files,
roughly one per implementation. Additionally it moves the definitions of
exceptions in new.cpp into the correct implementation header.
This patch also removes an unmaintained libc++abi configuration.
This configuration may still be used by Apple internally but there
are no other possible users. If it turns out that Apple still uses
this configuration internally I will re-add it in a later commit.
See http://llvm.org/PR31904.
llvm-svn: 294730
This patch contains multiple cleanups and fixes to better support building on
Windows.
* [Test] Fix handling of library runtime search paths by correctly adding them
to the PATH variable when running the tests.
* [Test] Don't explicitly force "--target=i686-pc-windows" when running the
test suite. Clang++ seems to deduce the correct target.
* [Test] Fix `.sh.cpp` tests on Windows by properly escaping flags used in
shell commands. Specifically windows style paths which included spaces
were causing these tests to fail.
* [CMake] Add "vcruntime" to the list of supported C++ ABI libraries in CMake, and
teach the test suite how to handle it. For now libc++ defaults to using
"vcruntime" on Windows except when libc++abi is in tree; That is probably
a bug and should be changed to always use vcruntime, at least for now.
* [Misc] Move the "c++-build" include directory to the libc++ binary dir
instead of the top level project dir and rename it "c++build". This is just
misc cleanup. Libc++ shouldn't be creating internal build files and directories
at the top-level projects root.
* [Misc] Build type_info's destructor when building for MSVC. This is a temporary
work around to prevent link errors until we have a proper type_info
implementation.
llvm-svn: 292157
Summary:
This patch attempts to fix the libc++ build/link so that it doesn't use an default C++ libraries on Windows. This is needed to prevent linking to MSVC's STL library.
Additionally this patch changes libc++ so that it is always linked with the non-debug DLL's (e.g. `/MD`). This is needed so that the test suite can correctly link the same libraries without needing to know which configuration `c++.dll` was linked with.
Reviewers: compnerd, rnk, majnemer, kimgr, awson, halyavin, smeenai
Subscribers: cfe-commits, mgorny
Differential Revision: https://reviews.llvm.org/D28441
llvm-svn: 292001
This patch adjusts the out-of-tree CMake configuration so that
the stderr output is ignored when an old llvm-config is found
that doesn't support --cmakedir.
llvm-svn: 291991
This is to make sure this check is called even when building as
part of LLVM runtimes when we are doing standalone but not out of
tree build.
Differential Revision: https://reviews.llvm.org/D28392
llvm-svn: 291592
Use the new --cmakedir option to obtain LLVM_CMAKE_PATH straight from
llvm-config. Fallback to local reconstruction if llvm-config does not
support this option.
llvm-svn: 291508
This patch re-commits a previous attempt to support building libc++ w/o
an ABI library. That patch was originally reverted because:
1) It forgot to teach the test suite about "default" ABI libraries.
2) Some LLVM builders don't clear the CMake cache between builds. The previous
patch caused those builders to fail since their old cache entry for
LIBCXX_CXX_ABI="" is no longer valid.
The updated patch addresses both issues. It works around (2) by adding
a hack to force the builders to update their cache entries. The hack will
be removed shortly once all LLVM builders have run.
Original commit message
-----------------------
Typically libc++ uses libc++abi or libcxxrt to provide the ABI and runtime bits
of the C++ STL. However we also support building w/o an ABI library entirely.
This patch fixes building libc++ w/o an ABI library (and incorporates the
`~type_info()` fix in D28211).
The main changes in this patch are:
1) Add `-DLIBCXX_CXX_ABI=default` instead of using the empty string to mean "default".
2) Fix CMake bits which treated "none" as "default" on OS X.
3) Teach the source files to respect `-D_LIBCPP_BUILDING_HAS_NO_ABI_LIBRARY`.
4) Define ~type_info() when _LIBCPP_BUILDING_HAS_NO_ABI_LIBRARY is defined.
Unfortunately this patch doesn't help clean up the macro mess that we use to
configure for different ABI libraries.
llvm-svn: 290849
Typically libc++ uses libc++abi or libcxxrt to provide the ABI and runtime bits
of the C++ STL. However we also support building w/o an ABI library entirely.
This patch fixes building libc++ w/o an ABI library (and incorporates the
`~type_info()` fix in D28211).
The main changes in this patch are:
1) Add `-DLIBCXX_CXX_ABI=default` instead of using the empty string to mean "default".
2) Fix CMake bits which treated "none" as "default" on OS X.
3) Teach the source files to respect `-D_LIBCPP_BUILDING_HAS_NO_ABI_LIBRARY`.
4) Define ~type_info() when _LIBCPP_BUILDING_HAS_NO_ABI_LIBRARY is defined.
Unfortunately this patch doesn't help clean up the macro mess that we use to
configure for different ABI libraries.
llvm-svn: 290839
This patch changes where the C++ ABI headers are put during the build. Previously
they were put in the top level include directory (not the libc++ header directory).
However that just polutes the top level directory. Instead this patch creates a special
directory to put them in. The reason they can't be put under c++/v1 until after the build
is because libc++ uses the in-source headers, so we can't add the include path of the libc++
headers in the object dir.
Additionally this patch teaches the test suite how to find the ABI headers,
and adds a demangling utility to help debug tests with.
llvm-svn: 289195
This patch adds a `check-cxx-abilist` target which verifies the libc++.so ABI
when the current build configuration matches the configuration used to generate
the ABI lists.
In order to make this change `HandleOutOfTreeLLVM.cmake` needed to be modified
to include `LLVMConfig.cmake` so that `TARGET_TRIPLE` is defined. Hopefully
the changes needed to accommodate this won't break existing build
configurations.
llvm-svn: 286789
Adjust the stand-alone build files to accept either CMake files from
LLVM_CMAKE_PATH or from LLVM_MAIN_SRC_DIR instead of requiring both.
This makes it possible to run libcxx tests on top of installed LLVM
and lit, without having to unpack a copy of LLVM sources. Furthermore,
it avoids adding duplicate paths.
Differential Revision: https://reviews.llvm.org/D25093
llvm-svn: 284583
In r280108 I tried to make the headers copy relative to LLVM_BINARY_DIR, and the intent was that it would only happen on in-tree builds or runtimes directory builds. It didn't actually work that way.
This patch adds a check for CMAKE_SOURCE_DIR being equal to CMAKE_CURRENT_SOURCE_DIR. In this case we set a variable LIBCXX_USING_INSTLLED_LLVM. This doesn't necessarily mean the LLVM is installed (it could be a build directory), but it means we need to treat the LLVM directory as read-only.
llvm-svn: 280400
We're compiling libc++ with -nodefaultlibs, so we should also pass this
option during the configuration checks to ensure those checks are
consistent with the actual build.
The primary motivation here is to ease cross-compilation against a
non-standard set of C++ libraries. Previously, the configuration checks
would attempt to link against the standard C++ libraries, which would
cause link failures when cross-compiling, even though the actual library
link would go through correctly (because of the use of -nodefaultlibs
and explicitly specifying any needed libraries). This is more correct
even ignoring the motivation, however.
Patch by Shoaib Meenai!
llvm-svn: 280015
Summary:
The new LLVM runtimes build directory requires some basic conventions across the runtime projects. These changes make libcxx build under the runtimes subdirectory. The general idea of the changes is that the runtimes subdirectory requires some conventions to be consistent across runtime projects.
I expect to have a few more small patches that build on this to tie up check targets and other things useful in development workflows.
Summary of changes in this patch:
* Renamed variable LLVM_CONFIG -> LLVM_CONFIG_PATH
* Renamed variable LIBCXX_BUILT_STANDALONE -> LIBCXX_STANDALONE_BUILD
* Add an include of AddLLVM in the tests subdirectory for add_lit_testsuite.
Reviewers: EricWF
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D23696
llvm-svn: 279151
This patch updates the way libc++ handles checking for libatomic, in part
to prepare for https://reviews.llvm.org/D22073.
Changes:
* 'LIBCXX_HAS_ATOMIC_LIB' is now set whenever libatomic is available even libc++
doesn't need to manually link it.
* 'LIBCXX_HAVE_CXX_ATOMICS_WITH_LIB' is now used to detect when libatomic
needs to be manually linked.
* 'LIBCXX_HAS_ATOMIC_LIB' now adds 'libatomic' as a available feature in the
test suite.
llvm-svn: 275759
Summary:
This patch changes the libc++ CMake so that it adds certain target flags like '-m32' or '--gcc-toolchain' before including config-ix.cmake.
Since these flags can affect things like check_library_exists([...]) they needed to be added before the tests are performed.
This patch fixes:
https://llvm.org/bugs/show_bug.cgi?id=24322
Reviewers: danalbert, jroelofs, bcraig, compnerd
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D20887
llvm-svn: 271460
Summary:
Currently libc++experimental builds with C++11. This patch changes that to C++14 when supported by the compiler. Although nothing currently requires C++14 the upcoming <experimental/memory_resource> implementation would benefit from it. [1]
Note that libc++.so continues to build with C++11 and is unaffected by this change.
[1] <experimental/memory_resource> provides global resources which must exist for the entire lifetime of the program. In order to ensure that a global resource can be used during program termination there destructors must never be invoked. The only way to do this, while also allowing "constant initialization", is to use a C++14 union.
Reviewers: mclow.lists
Subscribers: pete, cfe-commits
Differential Revision: http://reviews.llvm.org/D19992
llvm-svn: 269070
This should fix PR26631, PR26622 and has the nice property that the addition
of the CheckLibcxxAtomic.cmake module acts as an NFC on the platforms of the
reporters (at least for the time being).
As these bug reports explain, CMake fails the atomic check because the
include headers might not exist in the host environment. We could
potentially point to the headers provided by libcxx itself.
llvm-svn: 260961
Petr Hosek