[libcxx] Capture configuration information when installing the libc++ headers
Summary:
Hi all,
This patch is a successor to D11963. However it has changed dramatically and I felt it would be best to start a new review thread.
Please read the design documentation added in this patch for a description of how it works.
Reviewers: mclow.lists, danalbert, jroelofs, EricWF
Subscribers: vkalintiris, rnk, ed, espositofulvio, asl, eugenis, cfe-commits
Differential Revision: http://reviews.llvm.org/D13407
llvm-svn: 250235
2015-10-14 06:12:02 +08:00
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
//
|
|
|
|
// The LLVM Compiler Infrastructure
|
|
|
|
//
|
|
|
|
// This file is dual licensed under the MIT and the University of Illinois Open
|
|
|
|
// Source Licenses. See LICENSE.TXT for details.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
#ifndef _LIBCPP_CONFIG_SITE
|
|
|
|
#define _LIBCPP_CONFIG_SITE
|
|
|
|
|
2015-10-14 07:48:28 +08:00
|
|
|
#cmakedefine _LIBCPP_ABI_VERSION @_LIBCPP_ABI_VERSION@
|
|
|
|
#cmakedefine _LIBCPP_ABI_UNSTABLE
|
2017-10-05 10:18:08 +08:00
|
|
|
#cmakedefine _LIBCPP_ABI_FORCE_ITANIUM
|
|
|
|
#cmakedefine _LIBCPP_ABI_FORCE_MICROSOFT
|
[libcxx] By default, do not use internal_linkage to hide symbols from the ABI
Summary:
https://reviews.llvm.org/D49240 led to symbol size problems in Chromium, and
we expect this may be the case in other projects built in debug mode too.
Instead, unless users explicitly ask for internal_linkage, we use always_inline
like we used to.
In the future, when we have a solution that allows us to drop always_inline
without falling back on internal_linkage, we can replace always_inline by
that.
Note that this commit introduces a change in contract for existing libc++
users: by default, libc++ used to guarantee that TUs built with different
versions of libc++ could be linked together. With the introduction of the
_LIBCPP_HIDE_FROM_ABI_PER_TU macro, the default behavior is that TUs built
with different libc++ versions are not guaranteed to link. This is a change
in contract but not a change in behavior, since the current implementation
still allows linking TUs built with different libc++ versions together.
Reviewers: EricWF, mclow.lists, dexonsmith, hans, rnk
Subscribers: christof, cfe-commits
Differential Revision: https://reviews.llvm.org/D50652
llvm-svn: 339874
2018-08-16 20:44:28 +08:00
|
|
|
#cmakedefine _LIBCPP_HIDE_FROM_ABI_PER_TU_BY_DEFAULT
|
[libcxx] Capture configuration information when installing the libc++ headers
Summary:
Hi all,
This patch is a successor to D11963. However it has changed dramatically and I felt it would be best to start a new review thread.
Please read the design documentation added in this patch for a description of how it works.
Reviewers: mclow.lists, danalbert, jroelofs, EricWF
Subscribers: vkalintiris, rnk, ed, espositofulvio, asl, eugenis, cfe-commits
Differential Revision: http://reviews.llvm.org/D13407
llvm-svn: 250235
2015-10-14 06:12:02 +08:00
|
|
|
#cmakedefine _LIBCPP_HAS_NO_GLOBAL_FILESYSTEM_NAMESPACE
|
|
|
|
#cmakedefine _LIBCPP_HAS_NO_STDIN
|
|
|
|
#cmakedefine _LIBCPP_HAS_NO_STDOUT
|
|
|
|
#cmakedefine _LIBCPP_HAS_NO_THREADS
|
|
|
|
#cmakedefine _LIBCPP_HAS_NO_MONOTONIC_CLOCK
|
|
|
|
#cmakedefine _LIBCPP_HAS_NO_THREAD_UNSAFE_C_FUNCTIONS
|
2015-11-09 18:21:04 +08:00
|
|
|
#cmakedefine _LIBCPP_HAS_MUSL_LIBC
|
2016-05-26 01:40:09 +08:00
|
|
|
#cmakedefine _LIBCPP_HAS_THREAD_API_PTHREAD
|
[libcxx] Introduce an externally-threaded libc++ variant.
This patch further decouples libc++ from pthread, allowing libc++ to be built
against other threading systems. There are two main use cases:
- Building libc++ against a thread library other than pthreads.
- Building libc++ with an "external" thread API, allowing a separate library to
provide the implementation of that API.
The two use cases are quite similar, the second one being sligtly more
de-coupled than the first. The cmake option LIBCXX_HAS_EXTERNAL_THREAD_API
enables both kinds of builds. One needs to place an <__external_threading>
header file containing an implementation of the "libc++ thread API" declared
in the <__threading_support> header.
For the second use case, the implementation of the libc++ thread API can
delegate to a custom "external" thread API where the implementation of this
external API is provided in a seperate library. This mechanism allows toolchain
vendors to distribute a build of libc++ with a custom thread-porting-layer API
(which is the "external" API above), platform vendors (recipients of the
toolchain/libc++) are then required to provide their implementation of this API
to be linked with (end-user) C++ programs.
Note that the second use case still requires establishing the basic types that
get passed between the external thread library and the libc++ library
(e.g. __libcpp_mutex_t). These cannot be opaque pointer types (libc++ sources
won't compile otherwise). It should also be noted that the second use case can
have a slight performance penalty; as all the thread constructs need to cross a
library boundary through an additional function call.
When the header <__external_threading> is omitted, libc++ is built with the
"libc++ thread API" (declared in <__threading_support>) as the "external" thread
API (basic types are pthread based). An implementation (pthread based) of this
API is provided in test/support/external_threads.cpp, which is built into a
separate DSO and linked in when running the libc++ test suite. A test run
therefore demonstrates the second use case (less the intermediate custom API).
Differential revision: https://reviews.llvm.org/D21968
Reviewers: bcraig, compnerd, EricWF, mclow.lists
llvm-svn: 281179
2016-09-12 05:46:40 +08:00
|
|
|
#cmakedefine _LIBCPP_HAS_THREAD_API_EXTERNAL
|
2018-01-06 04:48:29 +08:00
|
|
|
#cmakedefine _LIBCPP_HAS_THREAD_API_WIN32
|
2017-01-07 04:05:40 +08:00
|
|
|
#cmakedefine _LIBCPP_HAS_THREAD_LIBRARY_EXTERNAL
|
2016-12-06 03:40:12 +08:00
|
|
|
#cmakedefine _LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS
|
2017-10-10 03:25:17 +08:00
|
|
|
#cmakedefine _LIBCPP_NO_VCRUNTIME
|
[libcxx] Capture configuration information when installing the libc++ headers
Summary:
Hi all,
This patch is a successor to D11963. However it has changed dramatically and I felt it would be best to start a new review thread.
Please read the design documentation added in this patch for a description of how it works.
Reviewers: mclow.lists, danalbert, jroelofs, EricWF
Subscribers: vkalintiris, rnk, ed, espositofulvio, asl, eugenis, cfe-commits
Differential Revision: http://reviews.llvm.org/D13407
llvm-svn: 250235
2015-10-14 06:12:02 +08:00
|
|
|
|
2017-10-05 07:17:12 +08:00
|
|
|
@_LIBCPP_ABI_DEFINES@
|
|
|
|
|
2015-11-09 18:21:04 +08:00
|
|
|
#endif // _LIBCPP_CONFIG_SITE
|