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.

49 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
//
//===----------------------------------------------------------------------===//
[libc++][NFC] Fix include guards and add a missing license header
2022-03-24 01:11:04 +08:00
#ifndef _LIBCPP___CONFIG_SITE
#define _LIBCPP___CONFIG_SITE
[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
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@
[libc++] Remove _LIBCPP_ABI_UNSTABLE Previously, _LIBCPP_ABI_UNSTABLE would be used interchangeably with _LIBCPP_ABI_VERSION >= 2. This was confusing and creating unnecessary complexity. This patch removes _LIBCPP_ABI_UNSTABLE -- instead, the LIBCXX_ABI_UNSTABLE CMake option will result in the LIBCXX_ABI_VERSION being set to '2', the current unstable ABI. As a result, in the code, we only have _LIBCPP_ABI_VERSION to check in order to query the current ABI version. As a fly-by, this also defines the ABI namespace during CMake configuration to reduce complexity in __config. I believe it was previously done this way because we used to try to use __config_site as seldom as possible. Now that we always ship a __config_site, it doesn't really matter and I think being explicit about how the library is configured in the __config_site is actually a feature. Differential Revision: https://reviews.llvm.org/D119173
2022-02-08 03:52:17 +08:00
#cmakedefine _LIBCPP_ABI_NAMESPACE @_LIBCPP_ABI_NAMESPACE@
[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] 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_THREADS
#cmakedefine _LIBCPP_HAS_NO_MONOTONIC_CLOCK
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@
[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++] Add an option to disable wide character support in libc++ Some embedded platforms do not wish to support the C library functionality for handling wchar_t because they have no use for it. It makes sense for libc++ to work properly on those platforms, so this commit adds a carve-out of functionality for wchar_t. Unfortunately, unlike some other carve-outs (e.g. random device), this patch touches several parts of the library. However, despite the wide impact of this patch, I still think it is important to support this configuration since it makes it much simpler to port libc++ to some embedded platforms. Differential Revision: https://reviews.llvm.org/D111265
2021-08-24 03:32:36 +08:00
#cmakedefine _LIBCPP_HAS_NO_WIDE_CHARACTERS
[libc++] Add a lightweight overridable assertion handler This patch adds a lightweight assertion handler mechanism that can be overriden at link-time in a fashion similar to `operator new`. This is a third take on https://llvm.org/D121123 (which allowed customizing the assertion handler at compile-time), and https://llvm.org/D119969 (which allowed customizing the assertion handler at runtime only). This approach is, I think, the best of all three explored approaches. Indeed, replacing the assertion handler in user code is ergonomic, yet we retain the ability to provide a custom assertion handler when deploying to older platforms that don't have a default handler in the dylib. As-is, this patch provides a pretty good amount of backwards compatibility with the previous debug mode: - Code that used to set _LIBCPP_DEBUG=0 in order to get basic assertions in their code will still get basic assertions out of the box, but those assertions will be using the new assertion handler support. - Code that was previously compiled with references to __libcpp_debug_function and friends will work out-of-the-box, no changes required. This is because we provide the same symbols in the dylib as we used to. - Code that used to set a custom __libcpp_debug_function will stop compiling, because we don't provide that declaration anymore. Users will have to migrate to the new way of setting a custom assertion handler, which is extremely easy. I suspect that pool of users is very limited, so breaking them at compile-time is probably acceptable. The main downside of this approach is that code being compiled with assertions enabled but deploying to an older platform where the assertion handler didn't exist yet will fail to compile. However users can easily fix the problem by providing a custom assertion handler and defining the _LIBCPP_AVAILABILITY_CUSTOM_ASSERTION_HANDLER_PROVIDED macro to let the library know about the custom handler. In a way, this is actually a feature because it avoids a load-time error that one would otherwise get when trying to run the code on the older target. Differential Revision: https://reviews.llvm.org/D121478
2022-03-04 06:37:03 +08:00
#cmakedefine01 _LIBCPP_ENABLE_ASSERTIONS_DEFAULT
[libc++] Make the Debug mode a configuration-time only option The debug mode has been broken pretty much ever since it was shipped because it was possible to enable the debug mode in user code without actually enabling it in the dylib, leading to ODR violations that caused various kinds of failures. This commit makes the debug mode a knob that is configured when building the library and which can't be changed afterwards. This is less flexible for users, however it will actually work as intended and it will allow us, in the future, to add various kinds of checks that do not assume the same ABI as the normal library. Furthermore, this will make the debug mode more robust, which means that vendors might be more tempted to support it properly, which hasn't been the case with the current debug mode. This patch shouldn't break any user code, except folks who are building against a library that doesn't have the debug mode enabled and who try to enable the debug mode in their code. Such users will get a compile-time error explaining that this configuration isn't supported anymore. In the future, we should further increase the granularity of the debug mode checks so that we can cherry-pick which checks to enable, like we do for unspecified behavior randomization. Differential Revision: https://reviews.llvm.org/D122941
2022-04-02 04:38:30 +08:00
#cmakedefine _LIBCPP_ENABLE_DEBUG_MODE
[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++] Use -I instead of -isystem to include headers in the test suite Using -isystem marks the headers as system headers, which means that we don't actually get all the warnings that we'd normally get if we included the headers as user headers. The goal of the test suite is normally to mirror as closely as possible how users would use the library. Technically, this change goes against that philosophy, since users should be using `-isystem` (if they ever need to specify the libc++ path explicitly, which should be a rare occurence). However, I believe fishing out additional warnings from the headers provides more value, hence this change. Ideally, we'd be able to still use `-isystem`, but instruct Clang to still emit warnings from the libc++ headers (e.g. we could tell Clang to emit warnings in any file inside `<...>/usr/include/c++/v1`). Reviewed By: #libc, ldionne, #libc_abi Spies: Mordante, EricWF, mstorsjo, mgorny, aheejin, arichardson, philnik, jloser, libcxx-commits Differential Revision: https://reviews.llvm.org/D118616
2022-03-03 19:10:30 +08:00
// __USE_MINGW_ANSI_STDIO gets redefined on MinGW
#ifdef __clang__
# pragma clang diagnostic push
# pragma clang diagnostic ignored "-Wmacro-redefined"
#endif
[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@
[libcxx] Add LIBCXX_EXTRA_SITE_DEFINES for adding extra defines in __config_site This is similar to the existing setting LIBCXX_ABI_DEFINES, with the difference that this also allows setting other defines than ones that start with "_LIBCPP_ABI_", and allows setting defines to a specific value. This allows avoiding using LIBCXX_TEST_COMPILER_FLAGS in two CI configurations. Differential Revision: https://reviews.llvm.org/D116109
2021-12-21 07:19:34 +08:00
@_LIBCPP_EXTRA_SITE_DEFINES@
[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
[libc++] Use -I instead of -isystem to include headers in the test suite Using -isystem marks the headers as system headers, which means that we don't actually get all the warnings that we'd normally get if we included the headers as user headers. The goal of the test suite is normally to mirror as closely as possible how users would use the library. Technically, this change goes against that philosophy, since users should be using `-isystem` (if they ever need to specify the libc++ path explicitly, which should be a rare occurence). However, I believe fishing out additional warnings from the headers provides more value, hence this change. Ideally, we'd be able to still use `-isystem`, but instruct Clang to still emit warnings from the libc++ headers (e.g. we could tell Clang to emit warnings in any file inside `<...>/usr/include/c++/v1`). Reviewed By: #libc, ldionne, #libc_abi Spies: Mordante, EricWF, mstorsjo, mgorny, aheejin, arichardson, philnik, jloser, libcxx-commits Differential Revision: https://reviews.llvm.org/D118616
2022-03-03 19:10:30 +08:00
#ifdef __clang__
# pragma clang diagnostic pop
#endif
[libc++][NFC] Fix include guards and add a missing license header
2022-03-24 01:11:04 +08:00
#endif // _LIBCPP___CONFIG_SITE