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

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

267 lines
5.6 KiB
CMake
Raw Normal View History

Reland "Use custom command and target to install libc++ headers" 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: 334468
2018-06-12 11:10:02 +08:00
set(files
[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
__availability
Reland "Use custom command and target to install libc++ headers" 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: 334468
2018-06-12 11:10:02 +08:00
__bit_reference
[libc++] Introduce __bits It has the low-level bit fiddling operations from bit. It eliminates a cyclic dependency between __bit_reference, bits, and vector. I want to exploit this in later patches. Reviewed By: #libc, ldionne Differential Revision: https://reviews.llvm.org/D94908
2021-01-18 20:21:00 +08:00
__bits
Reland "Use custom command and target to install libc++ headers" 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: 334468
2018-06-12 11:10:02 +08:00
__bsd_locale_defaults.h
__bsd_locale_fallbacks.h
[libc++] Include <__config_site> from <__config> Prior to this patch, we would generate a fancy <__config> header by concatenating <__config_site> and <__config>. This complexifies the build system and also increases the difference between what's tested and what's actually installed. This patch removes that complexity and instead simply installs <__config_site> alongside the libc++ headers. <__config_site> is then included by <__config>, which is much simpler. Doing this also opens the door to having different <__config_site> headers depending on the target, which was impossible before. It does change the workflow for testing header-only changes to libc++. Previously, we would run `lit` against the headers in libcxx/include. After this patch, we run it against a fake installation root of the headers (containing a proper <__config_site> header). This makes use closer to testing what we actually install, which is good, however it does mean that we have to update that root before testing header changes. Thus, we now need to run `ninja check-cxx-deps` before running `lit` by hand. Differential Revision: https://reviews.llvm.org/D97572
2020-06-27 00:08:59 +08:00
__config
Reland "Use custom command and target to install libc++ headers" 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: 334468
2018-06-12 11:10:02 +08:00
__debug
[libc++] Remove the ability to not install the support headers Those are part of the library, and shipping them just adds a tiny bit of size to the distribution. This was originally added in b422ecc7de0b to make it possible to match the Makefile build, which doesn't exist anymore. The upside is build system simplification.
2020-11-05 00:43:47 +08:00
__errc
Reland "Use custom command and target to install libc++ headers" 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: 334468
2018-06-12 11:10:02 +08:00
__functional_03
__functional_base
__functional_base_03
__hash_table
[libc++][NFC] Move incrementable_traits and indirectly_readable_traits into separate headers. Differential Revision: https://reviews.llvm.org/D100682
2021-04-20 02:28:27 +08:00
__iterator/concepts.h
__iterator/incrementable_traits.h
[libc++] Add std::ranges::iter_move and std::iter_rvalue_reference_t Original patch by @cjdb, modified by @ldionne. Differential Revision: https://reviews.llvm.org/D99873
2021-04-21 02:40:43 +08:00
__iterator/iter_move.h
__iterator/iterator_traits.h
[libc++][NFC] Move incrementable_traits and indirectly_readable_traits into separate headers. Differential Revision: https://reviews.llvm.org/D100682
2021-04-20 02:28:27 +08:00
__iterator/readable_traits.h
Reland "Use custom command and target to install libc++ headers" 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: 334468
2018-06-12 11:10:02 +08:00
__libcpp_version
__locale
[libc++] Split up __memory/base.h into meaningful headers
2021-04-15 01:59:03 +08:00
__memory/addressof.h
[libc++] Move __memory/utilities.h to __memory/allocation_guard.h This matches the granularity of other headers that were split off of <__memory>.
2021-04-15 02:00:48 +08:00
__memory/allocation_guard.h
[libc++] Split std::allocator out of <memory> Differential Revision: https://reviews.llvm.org/D100216
2021-04-10 00:48:34 +08:00
__memory/allocator.h
[libc++] Split allocator_traits and pointer_traits out of <memory> In addition to making the code a lot easier to grasp by localizing many helper functions to the only file where they are actually needed, this will allow creating helper functions that depend on allocator_traits outside of <memory>. This is done as part of implementing array support in allocate_shared, which requires non-trivial array initialization algorithms that would be better to keep out of <memory> for sanity. It's also a first step towards splitting up our monolithic headers into finer grained ones, which will make it easier to reuse functionality across the library. For example, it's just weird that we had to define `addressof` inside <type_traits> to avoid circular dependencies -- instead it's better to implement those in true helper headers. Differential Revision: https://reviews.llvm.org/D93074
2020-12-11 07:28:13 +08:00
__memory/allocator_traits.h
[libc++] Split auto_ptr out of <memory> Differential Revision: https://reviews.llvm.org/D100216
2021-04-10 00:44:26 +08:00
__memory/auto_ptr.h
[libc++] Split __compressed_pair out of <memory> Differential Revision: https://reviews.llvm.org/D100318
2021-04-10 02:43:01 +08:00
__memory/compressed_pair.h
[libc++] Split up __memory/base.h into meaningful headers
2021-04-15 01:59:03 +08:00
__memory/construct_at.h
[libc++] Move pointer safety related utilities out of <memory> Differential Revision: https://reviews.llvm.org/D100318
2021-04-10 03:57:21 +08:00
__memory/pointer_safety.h
[libc++] Split allocator_traits and pointer_traits out of <memory> In addition to making the code a lot easier to grasp by localizing many helper functions to the only file where they are actually needed, this will allow creating helper functions that depend on allocator_traits outside of <memory>. This is done as part of implementing array support in allocate_shared, which requires non-trivial array initialization algorithms that would be better to keep out of <memory> for sanity. It's also a first step towards splitting up our monolithic headers into finer grained ones, which will make it easier to reuse functionality across the library. For example, it's just weird that we had to define `addressof` inside <type_traits> to avoid circular dependencies -- instead it's better to implement those in true helper headers. Differential Revision: https://reviews.llvm.org/D93074
2020-12-11 07:28:13 +08:00
__memory/pointer_traits.h
[libc++] Split std::raw_storage_iterator out of <memory> Differential Revision: https://reviews.llvm.org/D100318
2021-04-10 02:45:18 +08:00
__memory/raw_storage_iterator.h
[libc++] Split std::shared_ptr & friends out of <memory> Differential Revision: https://reviews.llvm.org/D100318
2021-04-10 03:16:14 +08:00
__memory/shared_ptr.h
[libc++] Split std::get_temporary_buffer out of <memory> Differential Revision: https://reviews.llvm.org/D100216
2021-04-10 00:58:00 +08:00
__memory/temporary_buffer.h
[libc++] Split the memory-related algorithms out of <memory> Differential Revision: https://reviews.llvm.org/D100318
2021-04-10 02:47:46 +08:00
__memory/uninitialized_algorithms.h
[libc++] Split std::unique_ptr out of <memory> Differential Revision: https://reviews.llvm.org/D100318
2021-04-10 03:00:57 +08:00
__memory/unique_ptr.h
Reland "Use custom command and target to install libc++ headers" 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: 334468
2018-06-12 11:10:02 +08:00
__mutex_base
First half of C++17's splicing maps and sets This commit adds a node handle type, (located in __node_handle), and adds extract() and insert() members to all map and set types, as well as their implementations in __tree and __hash_table. The second half of this feature is adding merge() members, which splice nodes in bulk from one container into another. This will be committed in a follow-up. Differential revision: https://reviews.llvm.org/D46845 llvm-svn: 338472
2018-08-01 09:33:38 +08:00
__node_handle
Reland "Use custom command and target to install libc++ headers" 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: 334468
2018-06-12 11:10:02 +08:00
__nullptr
[libcxx][ranges] adds `range` access CPOs * `std::ranges::begin` * `std::ranges::cbegin` * `std::ranges::end` * `std::ranges::cend` * `std::ranges::iterator` (required for `end`) Implements parts of: * P0896R4 The One Ranges Proposal` Co-author: @zoecarver Depends on D90999, D100160. Differential Revision: https://reviews.llvm.org/D100255
2021-04-11 13:08:32 +08:00
__ranges/access.h
[libcxx][ranges] adds `ranges::range`, `ranges::common_range`, and range aliases * `std::ranges::range` * `std::ranges::sentinel_t` * `std::ranges::range_difference_t` * `std::ranges::range_value_t` * `std::ranges::range_reference_t` * `std::ranges::range_rvalue_reference_t` * `std::ranges::common_range` `range_size_t` depends on `sized_range` and will be added alongside it. Implements parts of: * P0896R4 The One Ranges Proposal` Depends on D100255. Differential Revision: https://reviews.llvm.org/D100269
2021-04-12 01:40:30 +08:00
__ranges/concepts.h
[libc++] Implements ranges::enable_borrowed_range This is the initial patch to implement ranges in libc++. Implements parts of: - P0896R4 One Ranges Proposal - P1870 forwarding-range is too subtle - LWG3379 in several library names is misleading Reviewed By: ldionne, #libc, cjdb, zoecarver, Quuxplusone Differential Revision: https://reviews.llvm.org/D90999
2020-11-25 01:08:02 +08:00
__ranges/enable_borrowed_range.h
Reland "Use custom command and target to install libc++ headers" 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: 334468
2018-06-12 11:10:02 +08:00
__split_buffer
__sso_allocator
__std_stream
__string
__threading_support
__tree
__tuple
__undef_macros
[libc++] Adds __utility/to_underlying.h. During the review of D97115 it was mentioned adding the `<utility>` header for `__to_underlying` was a bit unfortunate. Nowadays we tend to implement smaller headers, so a good reason to move `std::to_underlying` to its own header and adjust `<charconv>` to use the new header. Differential Revision: https://reviews.llvm.org/D101233
2021-04-24 23:28:35 +08:00
__utility/to_underlying.h
Reland "Use custom command and target to install libc++ headers" 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: 334468
2018-06-12 11:10:02 +08:00
algorithm
any
array
atomic
[libc++] Implementation of C++20's P1135R6 for libcxx Differential Revision: https://reviews.llvm.org/D68480
2020-02-18 22:58:34 +08:00
barrier
Recommit r339943 - Establish the <bit> header. NFC yet. Reviewed as https://reviews.llvm.org/D50815 - with a fix for the sanitizer bots llvm-svn: 340045
2018-08-18 00:07:48 +08:00
bit
Reland "Use custom command and target to install libc++ headers" 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: 334468
2018-06-12 11:10:02 +08:00
bitset
cassert
ccomplex
cctype
cerrno
cfenv
cfloat
[libc++][C++17] Elementary string conversions for integral types Summary: Major QoI considerations: - The facility is backported to C++14, same as libstdc++. - Efforts have been made to minimize the header dependencies. - The design is friendly to the uses of MSVC intrinsics (`__emulu`, `_umul128`, `_BitScanForward`, `_BitScanForward64`) but not implemented; future contributions are welcome. Thanks to Milo Yip for contributing the implementation of `__u64toa` and `__u32toa`. References: https://wg21.link/p0067r5 https://wg21.link/p0682r1 Reviewers: mclow.lists, EricWF Reviewed By: mclow.lists Subscribers: ldionne, Quuxplusone, christof, mgorny, cfe-commits Differential Revision: https://reviews.llvm.org/D41458 llvm-svn: 338479
2018-08-01 10:38:30 +08:00
charconv
Reland "Use custom command and target to install libc++ headers" 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: 334468
2018-06-12 11:10:02 +08:00
chrono
cinttypes
ciso646
climits
clocale
cmath
codecvt
compare
complex
complex.h
[libcxx] Adds [concept.same] Patch from Christopher Di Bella (cjdb@google.com) Reviewed as https://reviews.llvm.org/D74291 Adds `std::same_as` to libc++. Since there aren't clang-format rules for //requires-expressions//, I'll need to disable the formatter in certain areas.
2020-04-09 06:00:13 +08:00
concepts
Reland "Use custom command and target to install libc++ headers" 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: 334468
2018-06-12 11:10:02 +08:00
condition_variable
csetjmp
csignal
cstdarg
cstdbool
cstddef
cstdint
cstdio
cstdlib
cstring
ctgmath
ctime
ctype.h
cwchar
cwctype
deque
errno.h
exception
[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
execution
Reland "Use custom command and target to install libc++ headers" 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: 334468
2018-06-12 11:10:02 +08:00
experimental/__config
experimental/__memory
experimental/algorithm
experimental/coroutine
experimental/deque
experimental/filesystem
experimental/forward_list
experimental/functional
experimental/iterator
experimental/list
experimental/map
experimental/memory_resource
experimental/propagate_const
experimental/regex
experimental/set
experimental/simd
experimental/string
experimental/type_traits
experimental/unordered_map
experimental/unordered_set
experimental/utility
experimental/vector
ext/__hash
ext/hash_map
ext/hash_set
Add fenv.h header Summary: Some implementations of fenv.h use macros to define the functions they provide. This can cause problems when `std::fegetround()` is spelled in source. This patch adds a `fenv.h` header to libc++ for the sole purpose of turning those macros into real functions. Reviewers: rsmith, mclow.lists, ldionne Reviewed By: rsmith Subscribers: mgorny, christof, libcxx-commits Differential Revision: https://reviews.llvm.org/D57729 llvm-svn: 353767
2019-02-12 07:47:19 +08:00
fenv.h
Attempt to unbreak *all the bots* The bots were failing to build the cxx_filesystem target, so the tests were failing. Though this does lead me to wonder how it was ever working with c++experimental. llvm-svn: 338095
2018-07-27 11:42:58 +08:00
filesystem
Reland "Use custom command and target to install libc++ headers" 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: 334468
2018-06-12 11:10:02 +08:00
float.h
[libc++] Implement format_error. This is the first step at implementing <format>. It adds the <format> header and implements the `format_error`. class. Implemnts parts of: -P0645 Text Formatting Reviewed By: ldionne, #libc, miscco, curdeius Differential Revision: https://reviews.llvm.org/D92214
2020-11-27 02:12:18 +08:00
format
Reland "Use custom command and target to install libc++ headers" 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: 334468
2018-06-12 11:10:02 +08:00
forward_list
fstream
functional
future
initializer_list
inttypes.h
iomanip
ios
iosfwd
iostream
istream
iterator
[libc++] Implementation of C++20's P1135R6 for libcxx Differential Revision: https://reviews.llvm.org/D68480
2020-02-18 22:58:34 +08:00
latch
Reland "Use custom command and target to install libc++ headers" 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: 334468
2018-06-12 11:10:02 +08:00
limits
limits.h
list
locale
locale.h
map
math.h
memory
module.modulemap
mutex
new
[libc++] Implement <numbers> Summary: Constants have 33 significant decimal digits for IEEE 754 128-bit floating-point numbers. Reviewers: ldionne, #libc, EricWF, zoecarver, curdeius Reviewed By: ldionne, #libc, curdeius Differential Revision: https://reviews.llvm.org/D77505
2020-06-19 15:13:33 +08:00
numbers
Reland "Use custom command and target to install libc++ headers" 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: 334468
2018-06-12 11:10:02 +08:00
numeric
optional
ostream
queue
random
[libc++] Implements ranges::enable_borrowed_range This is the initial patch to implement ranges in libc++. Implements parts of: - P0896R4 One Ranges Proposal - P1870 forwarding-range is too subtle - LWG3379 in several library names is misleading Reviewed By: ldionne, #libc, cjdb, zoecarver, Quuxplusone Differential Revision: https://reviews.llvm.org/D90999
2020-11-25 01:08:02 +08:00
ranges
Reland "Use custom command and target to install libc++ headers" 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: 334468
2018-06-12 11:10:02 +08:00
ratio
[libcxx][ranges] adds `range` access CPOs * `std::ranges::begin` * `std::ranges::cbegin` * `std::ranges::end` * `std::ranges::cend` * `std::ranges::iterator` (required for `end`) Implements parts of: * P0896R4 The One Ranges Proposal` Co-author: @zoecarver Depends on D90999, D100160. Differential Revision: https://reviews.llvm.org/D100255
2021-04-11 13:08:32 +08:00
ranges
Reland "Use custom command and target to install libc++ headers" 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: 334468
2018-06-12 11:10:02 +08:00
regex
scoped_allocator
[libc++] Implementation of C++20's P1135R6 for libcxx Differential Revision: https://reviews.llvm.org/D68480
2020-02-18 22:58:34 +08:00
semaphore
Reland "Use custom command and target to install libc++ headers" 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: 334468
2018-06-12 11:10:02 +08:00
set
setjmp.h
shared_mutex
Implement <span>. Reviewed as https://reviews.llvm.org/D49338 llvm-svn: 337804
2018-07-24 11:01:02 +08:00
span
Reland "Use custom command and target to install libc++ headers" 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: 334468
2018-06-12 11:10:02 +08:00
sstream
stack
stdbool.h
stddef.h
stdexcept
stdint.h
stdio.h
stdlib.h
streambuf
string
string.h
string_view
strstream
[libc++] Rename include/support to include/__support We do ship those headers, so the directory name should not be something that can potentially conflict with user-defined directories. Differential Revision: https://reviews.llvm.org/D95956
2021-02-03 05:58:38 +08:00
__support/android/locale_bionic.h
__support/fuchsia/xlocale.h
[SystemZ][ZOS] Provide CLOCK_MONOTONIC alternative We need CLOCK_MONOTONIC equivalent implementation for z/OS within libc++. The default implementation is asserting. On z/OS the lack of 'clock_gettime()' and 'time_point()' force us to look for alternatives. The current proposal is to use `gettimeofday()` for CLOCK_MONOTONIC which is also used in CLOCK_REALTIME. This will allow us to skip the assertion with compromised CLOCK_MONOTONIC implementation which will not guarantee to never go back in time because it will use `gettimeofday()` but only when it's set. Is this a good compromise for platforms which does not support monotonic clock? Hopefully this will spark the discussion and agreement how to proceed in this situation. Reviewed By: #libc, ldionne, hubert.reinterpretcast Differential Revision: https://reviews.llvm.org/D93542
2021-02-13 02:36:15 +08:00
__support/ibm/gettod_zos.h
[libc++] Rename include/support to include/__support We do ship those headers, so the directory name should not be something that can potentially conflict with user-defined directories. Differential Revision: https://reviews.llvm.org/D95956
2021-02-03 05:58:38 +08:00
__support/ibm/limits.h
__support/ibm/locale_mgmt_aix.h
[SystemZ][z/OS] Missing locale functions libc++ The aim is to add the missing z/OS specific locale functions for libc++ (newlocale, freelocale and uselocale). Reviewed By: ldionne, #libc, curdeius Differential Revision: https://reviews.llvm.org/D98044
2021-03-09 03:20:22 +08:00
__support/ibm/locale_mgmt_zos.h
[libc++] Rename include/support to include/__support We do ship those headers, so the directory name should not be something that can potentially conflict with user-defined directories. Differential Revision: https://reviews.llvm.org/D95956
2021-02-03 05:58:38 +08:00
__support/ibm/nanosleep.h
__support/ibm/support.h
__support/ibm/xlocale.h
__support/musl/xlocale.h
__support/newlib/xlocale.h
__support/nuttx/xlocale.h
__support/openbsd/xlocale.h
__support/solaris/floatingpoint.h
__support/solaris/wchar.h
__support/solaris/xlocale.h
__support/win32/limits_msvc_win32.h
__support/win32/locale_win32.h
__support/xlocale/__nop_locale_mgmt.h
__support/xlocale/__posix_l_fallback.h
__support/xlocale/__strtonum_fallback.h
Reland "Use custom command and target to install libc++ headers" 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: 334468
2018-06-12 11:10:02 +08:00
system_error
tgmath.h
thread
tuple
type_traits
typeindex
typeinfo
unordered_map
unordered_set
utility
valarray
variant
vector
version
wchar.h
wctype.h
)
[libc++] Support per-target __config_site in per-target runtime build When using the per-target runtime build, it may be desirable to have different __config_site headers for each target where all targets cannot share a single configuration. The layout used for libc++ headers after this change is: ``` include/ c++/ v1/ <libc++ headers except for __config_site> <target1>/ c++/ v1/ __config_site <target2>/ c++/ v1/ __config_site <other targets> ``` This is the most optimal layout since it avoids duplication, the only headers that's per-target is __config_site, all other headers are shared across targets. This also means that we no need two -isystem flags: one for the target-agnostic headers and one for the target specific headers. Differential Revision: https://reviews.llvm.org/D89013
2020-07-16 05:10:56 +08:00
configure_file("__config_site.in" "${LIBCXX_GENERATED_INCLUDE_TARGET_DIR}/__config_site" @ONLY)
Reland "Use custom command and target to install libc++ headers" 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: 334468
2018-06-12 11:10:02 +08:00
[libc++] Support per-target __config_site in per-target runtime build When using the per-target runtime build, it may be desirable to have different __config_site headers for each target where all targets cannot share a single configuration. The layout used for libc++ headers after this change is: ``` include/ c++/ v1/ <libc++ headers except for __config_site> <target1>/ c++/ v1/ __config_site <target2>/ c++/ v1/ __config_site <other targets> ``` This is the most optimal layout since it avoids duplication, the only headers that's per-target is __config_site, all other headers are shared across targets. This also means that we no need two -isystem flags: one for the target-agnostic headers and one for the target specific headers. Differential Revision: https://reviews.llvm.org/D89013
2020-07-16 05:10:56 +08:00
set(_all_includes "${LIBCXX_GENERATED_INCLUDE_TARGET_DIR}/__config_site")
[libc++] Include <__config_site> from <__config> Prior to this patch, we would generate a fancy <__config> header by concatenating <__config_site> and <__config>. This complexifies the build system and also increases the difference between what's tested and what's actually installed. This patch removes that complexity and instead simply installs <__config_site> alongside the libc++ headers. <__config_site> is then included by <__config>, which is much simpler. Doing this also opens the door to having different <__config_site> headers depending on the target, which was impossible before. It does change the workflow for testing header-only changes to libc++. Previously, we would run `lit` against the headers in libcxx/include. After this patch, we run it against a fake installation root of the headers (containing a proper <__config_site> header). This makes use closer to testing what we actually install, which is good, however it does mean that we have to update that root before testing header changes. Thus, we now need to run `ninja check-cxx-deps` before running `lit` by hand. Differential Revision: https://reviews.llvm.org/D97572
2020-06-27 00:08:59 +08:00
foreach(f ${files})
set(src "${CMAKE_CURRENT_SOURCE_DIR}/${f}")
set(dst "${LIBCXX_GENERATED_INCLUDE_DIR}/${f}")
[runtimes] Revert the libc++ __config_site change This is a massive revert of the following commits (from most revent to oldest): 2b9b7b5775a1d8fcd7aa5abaa8fc0bc303434f1a. 529ac33197f6408952ae995075ac5e2dc5287e81 28270234f1478047e35879f4ba8838b47edfcc14 69c2087283cf7b17ca75f69daebf4ffc158b754a b5aa67446e01bd277727b05710a42e69ac41e74b 5d796645d6c8cadeb003715c33e231a8ba05b6de After checking-in the __config_site change, a lot of things started breaking due to widespread reliance on various aspects of libc++'s build, notably the fact that we can include the headers from the source tree, but also reliance on various "internal" CMake variables used by the runtimes build and compiler-rt. These were unintended consequences of the change, and after two days, we still haven't restored all the bots to being green. Instead, now that I understand what specific areas this will blow up in, I should be able to chop up the patch into smaller ones that are easier to digest. See https://reviews.llvm.org/D89041 for more details on this adventure.
2020-10-23 21:32:50 +08:00
add_custom_command(OUTPUT ${dst}
[libc++] Include <__config_site> from <__config> Prior to this patch, we would generate a fancy <__config> header by concatenating <__config_site> and <__config>. This complexifies the build system and also increases the difference between what's tested and what's actually installed. This patch removes that complexity and instead simply installs <__config_site> alongside the libc++ headers. <__config_site> is then included by <__config>, which is much simpler. Doing this also opens the door to having different <__config_site> headers depending on the target, which was impossible before. It does change the workflow for testing header-only changes to libc++. Previously, we would run `lit` against the headers in libcxx/include. After this patch, we run it against a fake installation root of the headers (containing a proper <__config_site> header). This makes use closer to testing what we actually install, which is good, however it does mean that we have to update that root before testing header changes. Thus, we now need to run `ninja check-cxx-deps` before running `lit` by hand. Differential Revision: https://reviews.llvm.org/D97572
2020-06-27 00:08:59 +08:00
DEPENDS ${src}
COMMAND ${CMAKE_COMMAND} -E copy_if_different ${src} ${dst}
COMMENT "Copying CXX header ${f}")
list(APPEND _all_includes "${dst}")
endforeach()
Reland "Use custom command and target to install libc++ headers" 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: 334468
2018-06-12 11:10:02 +08:00
Restore 8954fd436c7 after c06a8f9caa51c Else, just-built clang can't build programs that include libc++ headers on macOS if you build via the 'all' target.
2021-04-02 21:19:31 +08:00
add_custom_target(generate-cxx-headers ALL DEPENDS ${_all_includes})
[runtimes] Revert the libc++ __config_site change This is a massive revert of the following commits (from most revent to oldest): 2b9b7b5775a1d8fcd7aa5abaa8fc0bc303434f1a. 529ac33197f6408952ae995075ac5e2dc5287e81 28270234f1478047e35879f4ba8838b47edfcc14 69c2087283cf7b17ca75f69daebf4ffc158b754a b5aa67446e01bd277727b05710a42e69ac41e74b 5d796645d6c8cadeb003715c33e231a8ba05b6de After checking-in the __config_site change, a lot of things started breaking due to widespread reliance on various aspects of libc++'s build, notably the fact that we can include the headers from the source tree, but also reliance on various "internal" CMake variables used by the runtimes build and compiler-rt. These were unintended consequences of the change, and after two days, we still haven't restored all the bots to being green. Instead, now that I understand what specific areas this will blow up in, I should be able to chop up the patch into smaller ones that are easier to digest. See https://reviews.llvm.org/D89041 for more details on this adventure.
2020-10-23 21:32:50 +08:00
[libc++] Include <__config_site> from <__config> Prior to this patch, we would generate a fancy <__config> header by concatenating <__config_site> and <__config>. This complexifies the build system and also increases the difference between what's tested and what's actually installed. This patch removes that complexity and instead simply installs <__config_site> alongside the libc++ headers. <__config_site> is then included by <__config>, which is much simpler. Doing this also opens the door to having different <__config_site> headers depending on the target, which was impossible before. It does change the workflow for testing header-only changes to libc++. Previously, we would run `lit` against the headers in libcxx/include. After this patch, we run it against a fake installation root of the headers (containing a proper <__config_site> header). This makes use closer to testing what we actually install, which is good, however it does mean that we have to update that root before testing header changes. Thus, we now need to run `ninja check-cxx-deps` before running `lit` by hand. Differential Revision: https://reviews.llvm.org/D97572
2020-06-27 00:08:59 +08:00
add_library(cxx-headers INTERFACE)
add_dependencies(cxx-headers generate-cxx-headers ${LIBCXX_CXX_ABI_HEADER_TARGET})
# TODO: Use target_include_directories once we figure out why that breaks the runtimes build
if("${CMAKE_CXX_COMPILER_ID}" STREQUAL "MSVC" OR "${CMAKE_CXX_SIMULATE_ID}" STREQUAL "MSVC")
[libcxx] Use joined format for include flag on Windows Without this, CMake deduplicates the /I flag breaking the build. See https://cmake.org/cmake/help/v3.13/command/target_compile_options.html for more details on why this is needed. Differential Revision: https://reviews.llvm.org/D101550
2021-04-30 01:11:39 +08:00
target_compile_options(cxx-headers INTERFACE /I${LIBCXX_GENERATED_INCLUDE_DIR}
INTERFACE /I${LIBCXX_GENERATED_INCLUDE_TARGET_DIR})
Reland "Use custom command and target to install libc++ headers" 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: 334468
2018-06-12 11:10:02 +08:00
else()
[libc++] Support per-target __config_site in per-target runtime build When using the per-target runtime build, it may be desirable to have different __config_site headers for each target where all targets cannot share a single configuration. The layout used for libc++ headers after this change is: ``` include/ c++/ v1/ <libc++ headers except for __config_site> <target1>/ c++/ v1/ __config_site <target2>/ c++/ v1/ __config_site <other targets> ``` This is the most optimal layout since it avoids duplication, the only headers that's per-target is __config_site, all other headers are shared across targets. This also means that we no need two -isystem flags: one for the target-agnostic headers and one for the target specific headers. Differential Revision: https://reviews.llvm.org/D89013
2020-07-16 05:10:56 +08:00
target_compile_options(cxx-headers INTERFACE -I${LIBCXX_GENERATED_INCLUDE_DIR}
INTERFACE -I${LIBCXX_GENERATED_INCLUDE_TARGET_DIR})
[CMake] Copy headers relative to LLVM_BINARY_DIR Summary: This copy phase is only needed for in-tree builds, so we should be copying to the LLVM build directory's include dir instead of the sub-project include dir. Reviewers: bogner, EricWF Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D24015 llvm-svn: 280108
2016-08-31 00:51:34 +08:00
endif()
Make headers available in the build directory This essentially re-does r194825 and makes it possible to run clang with libc++ without having to install it, even if you don't have any version of libc++ installed in /usr/. This behaviour broke in r210577/r211629, which fixed pr18681. llvm-svn: 220489
2014-10-24 00:51:12 +08:00
Add option to turn off installation of headers. llvm-svn: 224162
2014-12-13 06:52:58 +08:00
if (LIBCXX_INSTALL_HEADERS)
Reland "Use custom command and target to install libc++ headers" 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: 334468
2018-06-12 11:10:02 +08:00
foreach(file ${files})
get_filename_component(dir ${file} DIRECTORY)
install(FILES ${file}
[libc++] Support per-target __config_site in per-target runtime build When using the per-target runtime build, it may be desirable to have different __config_site headers for each target where all targets cannot share a single configuration. The layout used for libc++ headers after this change is: ``` include/ c++/ v1/ <libc++ headers except for __config_site> <target1>/ c++/ v1/ __config_site <target2>/ c++/ v1/ __config_site <other targets> ``` This is the most optimal layout since it avoids duplication, the only headers that's per-target is __config_site, all other headers are shared across targets. This also means that we no need two -isystem flags: one for the target-agnostic headers and one for the target specific headers. Differential Revision: https://reviews.llvm.org/D89013
2020-07-16 05:10:56 +08:00
DESTINATION ${LIBCXX_INSTALL_INCLUDE_DIR}/${dir}
[CMake] Use -isystem flag to access libc++ headers This is a partial revert of D62155. Rather than copying libc++ headers into the build directory to be later overwritten by the final headers, use -isystem flag to access libc++ headers during CMake checks. This should address the occasional flake we've seen, especially on Windows builders where CMake fails to overwrite __config with the final version. Differential Revision: https://reviews.llvm.org/D88454
2020-09-29 07:12:48 +08:00
COMPONENT cxx-headers
Reland "Use custom command and target to install libc++ headers" 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: 334468
2018-06-12 11:10:02 +08:00
PERMISSIONS OWNER_READ OWNER_WRITE GROUP_READ WORLD_READ
)
endforeach()
[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++] Include <__config_site> from <__config> Prior to this patch, we would generate a fancy <__config> header by concatenating <__config_site> and <__config>. This complexifies the build system and also increases the difference between what's tested and what's actually installed. This patch removes that complexity and instead simply installs <__config_site> alongside the libc++ headers. <__config_site> is then included by <__config>, which is much simpler. Doing this also opens the door to having different <__config_site> headers depending on the target, which was impossible before. It does change the workflow for testing header-only changes to libc++. Previously, we would run `lit` against the headers in libcxx/include. After this patch, we run it against a fake installation root of the headers (containing a proper <__config_site> header). This makes use closer to testing what we actually install, which is good, however it does mean that we have to update that root before testing header changes. Thus, we now need to run `ninja check-cxx-deps` before running `lit` by hand. Differential Revision: https://reviews.llvm.org/D97572
2020-06-27 00:08:59 +08:00
# Install the generated __config_site.
[libc++] Support per-target __config_site in per-target runtime build When using the per-target runtime build, it may be desirable to have different __config_site headers for each target where all targets cannot share a single configuration. The layout used for libc++ headers after this change is: ``` include/ c++/ v1/ <libc++ headers except for __config_site> <target1>/ c++/ v1/ __config_site <target2>/ c++/ v1/ __config_site <other targets> ``` This is the most optimal layout since it avoids duplication, the only headers that's per-target is __config_site, all other headers are shared across targets. This also means that we no need two -isystem flags: one for the target-agnostic headers and one for the target specific headers. Differential Revision: https://reviews.llvm.org/D89013
2020-07-16 05:10:56 +08:00
install(FILES ${LIBCXX_GENERATED_INCLUDE_TARGET_DIR}/__config_site
DESTINATION ${LIBCXX_INSTALL_INCLUDE_TARGET_DIR}
[libc++] Always generate a __config_site header Before this patch, the __config_site header was only generated when at least one __config_site macro needed to be defined. This lead to two different code paths in how libc++ is configured, depending on whether a __config_site header was generated or not. After this patch, the __config_site is always generated, but it can be empty in case there are no macros to define in it. More context on why this change is important -------------------------------------------- In addition to being confusing, this double-code-path situation lead to broken code being checked in undetected in 2405bd689815, which introduced the LIBCXX_HAS_MERGED_TYPEINFO_NAMES_DEFAULT CMake setting. Specifically, the _LIBCPP_HAS_MERGED_TYPEINFO_NAMES_DEFAULT <__config_site> macro was supposed NOT to be defined unless LIBCXX_HAS_MERGED_TYPEINFO_NAMES_DEFAULT was specified explicitly on the CMake command line. Instead, what happened is that it was defined to 0 if it wasn't specified explicitly and a <__config_site> header was generated. And defining that macro to 0 had the important effect of using the non-unique RTTI comparison implementation, which changes the ABI. This change in behavior wasn't noticed because the <__config_site> header is not generated by default. However, the Apple configuration does cause a <__config_site> header to be generated, which lead to the wrong RTTI implementation being used, and to https://llvm.org/PR45549. We came close to an ABI break in the dylib, but were saved due to a downstream-only change that overrode the decision of the <__config_site> for the purpose of RTTI comparisons in libc++abi. This is an incredible luck that we should not rely on ever again. While the problem itself was fixed with 2464d8135e2a by setting LIBCXX_HAS_MERGED_TYPEINFO_NAMES_DEFAULT explicitly in the Apple CMake cache and then in d0fcdcd28f95 by making the setting less brittle, the point still is that we should have had a single code path from the beginning. Unlike most normal libraries, the macros that configure libc++ are really complex, there's a lot of them and they control important properties of the C++ runtime. There must be a single code path for that, and it must be simple and robust. Differential Revision: https://reviews.llvm.org/D80927
2020-05-16 02:54:27 +08:00
PERMISSIONS OWNER_READ OWNER_WRITE GROUP_READ WORLD_READ
[CMake] Use -isystem flag to access libc++ headers This is a partial revert of D62155. Rather than copying libc++ headers into the build directory to be later overwritten by the final headers, use -isystem flag to access libc++ headers during CMake checks. This should address the occasional flake we've seen, especially on Windows builders where CMake fails to overwrite __config with the final version. Differential Revision: https://reviews.llvm.org/D88454
2020-09-29 07:12:48 +08:00
COMPONENT cxx-headers)
[CMake] Create a separate install target for libcxx headers This change doesn't impact the behavior of the install-libcxx target which installs whichever libcxx components you build, it just adds a separate target to just install the headers. llvm-svn: 268124
2016-04-30 06:17:15 +08:00
if (NOT CMAKE_CONFIGURATION_TYPES)
[CMake] Use -isystem flag to access libc++ headers This is a partial revert of D62155. Rather than copying libc++ headers into the build directory to be later overwritten by the final headers, use -isystem flag to access libc++ headers during CMake checks. This should address the occasional flake we've seen, especially on Windows builders where CMake fails to overwrite __config with the final version. Differential Revision: https://reviews.llvm.org/D88454
2020-09-29 07:12:48 +08:00
add_custom_target(install-cxx-headers
[libc++] Include <__config_site> from <__config> Prior to this patch, we would generate a fancy <__config> header by concatenating <__config_site> and <__config>. This complexifies the build system and also increases the difference between what's tested and what's actually installed. This patch removes that complexity and instead simply installs <__config_site> alongside the libc++ headers. <__config_site> is then included by <__config>, which is much simpler. Doing this also opens the door to having different <__config_site> headers depending on the target, which was impossible before. It does change the workflow for testing header-only changes to libc++. Previously, we would run `lit` against the headers in libcxx/include. After this patch, we run it against a fake installation root of the headers (containing a proper <__config_site> header). This makes use closer to testing what we actually install, which is good, however it does mean that we have to update that root before testing header changes. Thus, we now need to run `ninja check-cxx-deps` before running `lit` by hand. Differential Revision: https://reviews.llvm.org/D97572
2020-06-27 00:08:59 +08:00
DEPENDS cxx-headers
[CMake] Create a separate install target for libcxx headers This change doesn't impact the behavior of the install-libcxx target which installs whichever libcxx components you build, it just adds a separate target to just install the headers. llvm-svn: 268124
2016-04-30 06:17:15 +08:00
COMMAND "${CMAKE_COMMAND}"
[CMake] Use -isystem flag to access libc++ headers This is a partial revert of D62155. Rather than copying libc++ headers into the build directory to be later overwritten by the final headers, use -isystem flag to access libc++ headers during CMake checks. This should address the occasional flake we've seen, especially on Windows builders where CMake fails to overwrite __config with the final version. Differential Revision: https://reviews.llvm.org/D88454
2020-09-29 07:12:48 +08:00
-DCMAKE_INSTALL_COMPONENT=cxx-headers
[CMake] Create a separate install target for libcxx headers This change doesn't impact the behavior of the install-libcxx target which installs whichever libcxx components you build, it just adds a separate target to just install the headers. llvm-svn: 268124
2016-04-30 06:17:15 +08:00
-P "${CMAKE_BINARY_DIR}/cmake_install.cmake")
[libc++] Create install-stripped targets LLVM is gaining install-*-stripped targets to perform stripped installs, and in order for this to be useful for install-distribution, all potential distribution components should have stripped installation targets. LLVM has a function to create these install targets, but since we can't use LLVM CMake functions in libc++, let's do it manually. Differential Revision: https://reviews.llvm.org/D40680 llvm-svn: 319959
2017-12-07 05:03:42 +08:00
# Stripping is a no-op for headers
[CMake] Use -isystem flag to access libc++ headers This is a partial revert of D62155. Rather than copying libc++ headers into the build directory to be later overwritten by the final headers, use -isystem flag to access libc++ headers during CMake checks. This should address the occasional flake we've seen, especially on Windows builders where CMake fails to overwrite __config with the final version. Differential Revision: https://reviews.llvm.org/D88454
2020-09-29 07:12:48 +08:00
add_custom_target(install-cxx-headers-stripped DEPENDS install-cxx-headers)
[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
endif()
Add option to turn off installation of headers. llvm-svn: 224162
2014-12-13 06:52:58 +08:00
endif()