| 66134e8a5f7fc172dcc9124349047bb793affbaa |
|
06-Jan-2017 |
Eric Fiselier <eric@efcs.ca> |
[libc++] Cleanup and document <__threading_support>
Summary:
This patch attempts to clean up the macro configuration mess in `<__threading_support>`, specifically the mess involving external threading variants. Additionally this patch adds design documentation for `<__threading_support>` and the configuration macros it uses.
The primary change in this patch is separating the idea of an "external API" provided by `<__external_threading>` and the idea of having an external threading library. Now `_LIBCPP_HAS_THREAD_API_EXTERNAL` means that libc++ should use `<__external_threading>` and that the header is expected to exist. Additionally the new macro `_LIBCPP_HAS_THREAD_LIBRARY_EXTERNAL` is now used to configure for using an "external library" with the default threading API.
Reviewers: compnerd, rmaprath
Subscribers: smeenai, cfe-commits, mgorny
Differential Revision: https://reviews.llvm.org/D28316
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@291275 91177308-0d34-0410-b5e6-96231b3b80d8
/external/libcxx/include/__config_site.in
|
| c6d8e8a9cc5da3e006ad46e293797c5dcf847454 |
|
05-Dec-2016 |
Shoaib Meenai <smeenai@fb.com> |
[libc++] Add _LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS
It's useful to be able to disable visibility annotations entirely; for
example, if we're building libc++ static to include in another library,
and we don't want any libc++ functions getting exported out of that
library. This is a generalization of _LIBCPP_DISABLE_DLL_IMPORT_EXPORT.
Differential Revision: https://reviews.llvm.org/D26934
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@288690 91177308-0d34-0410-b5e6-96231b3b80d8
/external/libcxx/include/__config_site.in
|
| 74c9857af9dee33a24b72a8583160fe4786161c6 |
|
27-Sep-2016 |
Eric Fiselier <eric@efcs.ca> |
Expect DLL builds on Windows by default and require a custom __config for static
builds.
On Windows the __declspec(dllimport) and __declspec(dllexport) attributes
require linking to a DLL, not a static library. Previously these annotations
were disabled by default unless _LIBCPP_DLL was defined. However the DLL
configuration is probably the more common one, so it should be supported by
default.
This patch enables import/export attributes by default and adds a
_LIBCPP_DISABLE_DLL_IMPORT_EXPORT macro which can be used to disable this
behavior. If libc++ is built as a static library on Windows then a custom __config
header will be generated that predefines this macro.
This patch is based off work by Shoaib Meenai.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@282449 91177308-0d34-0410-b5e6-96231b3b80d8
/external/libcxx/include/__config_site.in
|
| 040945b81f11af65ac7544a005fde63a0e099cbd |
|
11-Sep-2016 |
Asiri Rathnayake <asiri.rathnayake@arm.com> |
[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
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@281179 91177308-0d34-0410-b5e6-96231b3b80d8
/external/libcxx/include/__config_site.in
|
| 5163e46afb226fc9828212dced562d547dc98e26 |
|
25-May-2016 |
Ben Craig <ben.craig@codeaurora.org> |
[libcxx] Allow explicit pthread opt-in
The existing pthread detection code in __config is pretty good for
common operating systems. It doesn't allow cmake-time choices to be
made for uncommon operating systems though.
This change adds the LIBCXX_HAS_PTHREAD_API cmake flag, which turns
into the _LIBCPP_HAS_THREAD_API_PTHREAD preprocessor define. This is
a name change from the old _LIBCPP_THREAD_API_PTHREAD. The lit tests
want __config_site.in variables to have a _LIBCPP_HAS prefix.
http://reviews.llvm.org/D20573
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@270735 91177308-0d34-0410-b5e6-96231b3b80d8
/external/libcxx/include/__config_site.in
|
| 579b42b413d327f246f2572dde145fd147395591 |
|
09-Nov-2015 |
Vasileios Kalintiris <Vasileios.Kalintiris@imgtec.com> |
Add initial support for the MUSL C library.
Summary:
This patch adds the LIBCXX_LIBC_IS_MUSL cmake option to allow the
building of libcxx with the Musl C library. The option is necessary as
Musl does not provide any predefined macro in order to test for its
presence, like GLIBC. Most of the changes specify the correct path to
choose through the various #if/#else constructs in the locale code.
Depends on D13407.
Reviewers: mclow.lists, jroelofs, EricWF
Subscribers: jfb, tberghammer, danalbert, srhines, cfe-commits
Differential Revision: http://reviews.llvm.org/D13673
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@252457 91177308-0d34-0410-b5e6-96231b3b80d8
/external/libcxx/include/__config_site.in
|
| 4f01aa8fb8bb7d09505aff519b5b7f3e85dc881c |
|
14-Oct-2015 |
Evgeniy Stepanov <eugeni.stepanov@gmail.com> |
ABI versioning macros for libc++.
C++ macros and CMake options that specify the default ABI version of
the library, and can be overridden to pick up new ABI-changing
features.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@250254 91177308-0d34-0410-b5e6-96231b3b80d8
/external/libcxx/include/__config_site.in
|
| 73ffc7861633630c9ad0f98fa1828ac5d93be6b9 |
|
14-Oct-2015 |
Eric Fiselier <eric@efcs.ca> |
[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
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@250235 91177308-0d34-0410-b5e6-96231b3b80d8
/external/libcxx/include/__config_site.in
|