maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/libcxx/include/__config_site.in

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

43 lines
1.7 KiB
Plaintext
Raw Normal View History

[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
//===----------------------------------------------------------------------===//
//
Update more file headers across all of the LLVM projects in the monorepo to reflect the new license. These used slightly different spellings that defeated my regular expressions. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351648
2019-01-19 18:56:40 +08:00
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
// See https://llvm.org/LICENSE.txt for license information.
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
[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
//
//===----------------------------------------------------------------------===//
#ifndef _LIBCPP_CONFIG_SITE
#define _LIBCPP_CONFIG_SITE
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. llvm-svn: 250254
2015-10-14 07:48:28 +08:00
#cmakedefine _LIBCPP_ABI_VERSION @_LIBCPP_ABI_VERSION@
#cmakedefine _LIBCPP_ABI_UNSTABLE
[libc++] Clarify names of ABI forcing macros Make it clear that these are intended only to force a specific ABI when the autodetection would give the wrong result by renaming the cmake options and adding separate forcing macros, as suggested by EricWF in the post-commit review of r314949 and further discussed on IRC. llvm-svn: 314965
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
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 llvm-svn: 252457
2015-11-09 18:21:04 +08:00
#cmakedefine _LIBCPP_HAS_MUSL_LIBC
[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 llvm-svn: 270735
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
[cmake] Add a config option LIBCXX_HAS_WIN32_THREAD_API for enforcing win32 threads This allows keeping libcxx using win32 threads even if a version of pthread.h is installed. This matches the existing cmake option LIBCXX_HAS_PTHREAD_API. Also add missing documentation about the internal define _LIBCPP_HAS_THREAD_API_WIN32. Differential Revision: https://reviews.llvm.org/D41764 llvm-svn: 321896
2018-01-06 04:48:29 +08:00
#cmakedefine _LIBCPP_HAS_THREAD_API_WIN32
[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 llvm-svn: 291275
2017-01-07 04:05:40 +08:00
#cmakedefine _LIBCPP_HAS_THREAD_LIBRARY_EXTERNAL
[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 llvm-svn: 288690
2016-12-06 03:40:12 +08:00
#cmakedefine _LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS
[libc++] Rework the whole availability markup implementation Currently, vendor-specific availability markup is enabled by default. This means that even when building against trunk libc++, the headers will by default prevent you from using some features that were not released in the dylib on your target platform. This is a source of frustration since people building libc++ from sources are usually not trying to use some vendor's released dylib. For that reason, I've been thinking for a long time that availability annotations should be off by default, which is the primary change that this commit enables. In addition, it reworks the implementation to make it easier for new vendors to add availability annotations for their platform, and it refreshes the documentation to reflect the current state of the codebase. Finally, a CMake configuration option is added to control whether availability annotations should be turned on for the flavor of libc++ being created. The intent is for vendors like Apple to turn it on, and for the upstream libc++ to leave it off (the default). Differential Revision: https://reviews.llvm.org/D90843
2020-11-05 04:01:25 +08:00
#cmakedefine _LIBCPP_HAS_NO_VENDOR_AVAILABILITY_ANNOTATIONS
[libc++] Support Microsoft ABI without vcruntime headers The vcruntime headers are hairy and clash with both libc++ headers themselves and other libraries. libc++ normally deals with the clashes by deferring to the vcruntime headers and silencing its own definitions, but for clients which don't want to depend on vcruntime headers, it's desirable to support the opposite, i.e. have libc++ provide its own definitions. Certain operator new/delete replacement scenarios are not currently supported in this mode, which requires some tests to be marked XFAIL. The added documentation has more details. Differential Revision: https://reviews.llvm.org/D38522 llvm-svn: 315234
2017-10-10 03:25:17 +08:00
#cmakedefine _LIBCPP_NO_VCRUNTIME
[libc++] Fix the LIBCXX_HAS_MERGED_TYPEINFO_NAMES_DEFAULT setting When the __config_site header is generated, but LIBCXX_HAS_MERGED_TYPEINFO_NAMES_DEFAULT wasn't specified, _LIBCPP_HAS_MERGED_TYPEINFO_NAMES_DEFAULT would be defined to 0, which was the NonUnique RTTI comparison implementation. The intent was to use the Unique RTTI comparison implementation in that case, which caused https://llvm.org/PR45549. Instead, use a proper "switch" to select the RTTI comparison implementation. Note that 0 can't be used as a value, because that is treated the same by CMake as a variable that is just not defined. Differential Revision: https://reviews.llvm.org/D80037
2020-05-16 03:58:19 +08:00
#cmakedefine _LIBCPP_TYPEINFO_COMPARISON_IMPLEMENTATION @_LIBCPP_TYPEINFO_COMPARISON_IMPLEMENTATION@
Make libc++'s versioning namespace customizable Summary: This patch makes the versioning namespace libc++ uses customizable by the user using `-DLIBCXX_ABI_NAMESPACE=__foo`. This allows users to build custom versions of libc++ which can be linked into binaries with other libc++ versions without causing symbol conflicts or ODR issues. Reviewers: mclow.lists, ldionne Reviewed By: ldionne Subscribers: kristina, smeenai, mgorny, phosek, libcxx-commits Differential Revision: https://reviews.llvm.org/D53879 llvm-svn: 345657
2018-10-31 05:44:53 +08:00
#cmakedefine _LIBCPP_ABI_NAMESPACE @_LIBCPP_ABI_NAMESPACE@
[libc++] Make LIBCXX_ENABLE_FILESYSTEM fully consistent Previously, LIBCXX_ENABLE_FILESYSTEM controlled only whether the filesystem support was compiled into libc++'s library. This commit promotes the setting to a first-class option like LIBCXX_ENABLE_LOCALIZATION, where the whole library is aware of the setting and features that depend on <filesystem> won't be provided at all. The test suite is also properly annotated such that tests that depend on <filesystem> are disabled when the library doesn't support it. This is an alternative to https://llvm.org/D94824, but also an improvement along the lines of LIBCXX_ENABLE_LOCALIZATION that I had been wanting to make for a while. Differential Revision: https://reviews.llvm.org/D94921
2021-01-19 01:18:18 +08:00
#cmakedefine _LIBCPP_HAS_NO_FILESYSTEM_LIBRARY
[libc++] Take 2: Integrate the PSTL into libc++ Summary: This commit allows specifying LIBCXX_ENABLE_PARALLEL_ALGORITHMS when configuring libc++ in CMake. When that option is enabled, libc++ will assume that the PSTL can be found somewhere on the CMake module path, and it will provide the C++17 parallel algorithms based on the PSTL (that is assumed to be available). The commit also adds support for running the PSTL tests as part of the libc++ test suite. The first attempt to commit this failed because it exposed a bug in the tests for modules. Now that this has been fixed, it should be safe to commit this. Reviewers: EricWF Subscribers: mgorny, christof, jkorous, dexonsmith, libcxx-commits, mclow.lists, EricWF Tags: #libc Differential Revision: https://reviews.llvm.org/D60480 llvm-svn: 367903
2019-08-06 02:29:14 +08:00
#cmakedefine _LIBCPP_HAS_PARALLEL_ALGORITHMS
[libc++] Allow building libc++ on platforms without a random device Some platforms, like several embedded platforms, do not provide a source of randomness through a random device. This commit makes it possible to build and test libc++ for such platforms, i.e. without std::random_device. Surprisingly, the only functionality that doesn't work on such platforms is std::random_device itself -- everything else in <random> still works, one just has to find alternative ways to seed the PRNGs.
2020-10-15 22:32:09 +08:00
#cmakedefine _LIBCPP_HAS_NO_RANDOM_DEVICE
[libc++] Add a libc++ configuration that does not support localization When porting libc++ to embedded systems, it can be useful to drop support for localization, which these systems don't implement or care about. Differential Revision: https://reviews.llvm.org/D90072
2020-10-10 03:31:05 +08:00
#cmakedefine _LIBCPP_HAS_NO_LOCALIZATION
[libc++] Disable incomplete library features. Adds a new CMake option to disable the usage of incomplete headers. These incomplete headers are not guaranteed to be ABI stable. This option is intended to be used by vendors so they can avoid their users from code that's not ready for production usage. The option is enabled by default. Differential Revision: https://reviews.llvm.org/D106763
2021-07-25 15:18:53 +08:00
#cmakedefine _LIBCPP_HAS_NO_INCOMPLETE_FORMAT
#cmakedefine _LIBCPP_HAS_NO_INCOMPLETE_RANGES
[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
[libc++] Add site config option for ABI macros Some ABI macros affect headers, so it's nice to have a site config option for them. Add a LIBCXX_ABI_DEFINES cmake macro to allow specifying a list of ABI macros to define in the site config. The primary design constraint (as discussed with Eric on IRC a while back) was to not have to repeat the ABI macro names in cmake, which only leaves a free-form cmake list as an option. A somewhat unfortunate consequence is that we can't verify that the ABI macros being defined actually exist, though we can at least perform some basic sanity checking, since all the ABI macros begin with _LIBCPP_ABI_. Differential Revision: https://reviews.llvm.org/D36719 llvm-svn: 314946
2017-10-05 07:17:12 +08:00
@_LIBCPP_ABI_DEFINES@
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 llvm-svn: 252457
2015-11-09 18:21:04 +08:00
#endif // _LIBCPP_CONFIG_SITE