summaryrefslogtreecommitdiffstats
path: root/libcxx/lib/CMakeLists.txt
Commit message (Collapse)AuthorAgeFilesLines
...
* [cmake] [libcxx] Call llvm_setup_rpath() when adding shared libraries.Don Hinton2018-01-251-0/+1
| | | | | | | | | Clang and llvm already use llvm_setup_rpath(), so this change will help standarize rpath usage across all projects. Differential Revision: https://reviews.llvm.org/D42459 llvm-svn: 323453
* [libc++] Create install-stripped targetsShoaib Meenai2017-12-061-0/+8
| | | | | | | | | | | | 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
* Use CMAKE_AR instead of the system default 'ar' for merging static librariesMartin Storsjo2017-09-131-0/+1
| | | | | | | | | | | | | | | Using the system default 'ar' might not be the right choice when cross compiling. Don't prepend the ar options by a dash, not all ar implementations support that (llvm-ar doesn't). Also pass the 's' option when creating the merged library, to create an index. Differential Revision: https://reviews.llvm.org/D37134 llvm-svn: 313122
* Add MINGW_LIBRARIES to the linker flagsMartin Storsjo2017-09-041-0/+1
| | | | | | | | | | This is essential when building with -nodefaultlibs. This is similar to what already is done in libcxxabi in SVN r302760. Differential revision: https://reviews.llvm.org/D37207 llvm-svn: 312498
* [CMake] Use MATCHES for regular expression.Leo Li2017-07-181-1/+1
| | | | | | | | Subscribers: mgorny Differential Revision: https://reviews.llvm.org/D35514 llvm-svn: 308347
* [libcxx][CMake] Add install path variable to allow overriding the destinationPetr Hosek2017-07-111-3/+3
| | | | | | | | | This is going to be used by the runtime build in the multi-target setup to allow using different install prefix for each target. Differential Revision: https://reviews.llvm.org/D33762 llvm-svn: 307615
* Move external instantiation for __vector_base_common to vector.cppEric Fiselier2017-06-151-0/+1
| | | | | | | | Previously the explicit instantiation for this was in locale.cpp, but that didn't make much sense. This patch creates a new vector.cpp source file to contain the explicit instantiation. llvm-svn: 305442
* libcxx: fix bootstrapping for mingw-w64Martell Malone2017-05-251-5/+2
| | | | | | Differential Revision: https://reviews.llvm.org/D33388 llvm-svn: 303928
* [libc++] Implement exception_ptr on WindowsEric Fiselier2017-05-081-0/+1
| | | | | | | | | | | | | | | | | | | | | | Summary: This patch implements exception_ptr on Windows using the `__ExceptionPtrFoo` functions provided by MSVC. The `__ExceptionPtrFoo` functions are defined inside the C++ standard library, `msvcprt`, which is unfortunate because it requires libc++ to link to the MSVC STL. However this doesn't seem to cause any immediate problems. However to be safe I kept all usages within the libc++ dylib so that user programs wouldn't have to link to MSVCPRT as well. Note there are still 2 outstanding exception_ptr/nested_exception test failures. * `current_exception.pass.cpp` needs to be rewritten for the Windows exception_ptr semantics which copy the exception every time. * `rethrow_if_nested.pass.cpp` need investigation. It hits a stack overflow, likely from recursion. This patch also gets most of the `<future>` tests passing as well. Reviewers: mclow.lists, compnerd, bcraig, rmaprath, majnemer, BillyONeal, STL_MSFT Subscribers: mgorny, cfe-commits Differential Revision: https://reviews.llvm.org/D32927 llvm-svn: 302393
* Rename the static version of libc++ on Windows.Eric Fiselier2017-04-201-1/+6
| | | | | | | | | | | Previously both the static version of libc++ and the import library for the DLL had the same name, 'c++.lib'. This patch renames the static library on Windows to be `libc++.lib` so it no longer conflicts. This naming convention is consistent with other windows libraries. llvm-svn: 300817
* [libcxx] Fix check-cxx-abilist on OS XEric Fiselier2017-04-151-6/+4
| | | | | | | | | | | | | | | | | | | | Summary: Recent commits broke the check-cxx-abilist by changing the default OS X to use `-rexport_library` instead of `-reexport_symbol_list`. Apparently `-reexport_library` doesn't export the symbols into `libc++.dylib`s symbol table, whereas `-reexport_symbol_list` does. This means the change removed ~500 symbols from the symbol table. I've been told this change is non ABI breaking, but it does make it harder to maintain the ABI lists, and hence the ABI. This patch fixes the issue by switching back to `-reexport_symbol_list`. It still avoid the issues fixed in r299052 by putting the new/delete symbols in a different symbol list file, which is only exported when LIBCXX_ENABLE_NEW_DELETE_DEFINITIONS in OFF. Reviewers: mehdi_amini, smeenai, dexonsmith Reviewed By: smeenai Subscribers: mgorny, cfe-commits Differential Revision: https://reviews.llvm.org/D31644 llvm-svn: 300390
* [CMake][libcxx] Use builtins rather than gcc_s when compiler-rt is requestedPetr Hosek2017-04-051-1/+6
| | | | | | | | | When compiler-rt is requested, we should attempt to link compiler-rt builtins library rather than gcc_s. Differential Revision: https://reviews.llvm.org/D31617 llvm-svn: 299599
* Do not pass an explicit reexported symbol list when building libc++ dylib if ↵Mehdi Amini2017-03-301-1/+5
| | | | | | also defining new/delete llvm-svn: 299052
* [libc++] Add a key function for bad_function_callShoaib Meenai2017-03-281-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: bad_function_call is currently an empty class, so any object files using that class will end up with their own copy of its typeinfo, typeinfo name and vtable, leading to unnecessary duplication that has to be resolved by the dynamic linker. Instead, give bad_function_call a key function and put a definition for that key function in libc++ itself, to centralize the typeinfo and vtable. This is consistent with the behavior for other exception classes. The key functions are defined in libc++ rather than libc++abi since the class is defined in the libc++ versioning namespace, so ABI compatibility with libstdc++ is not a concern. Guard this change behind an ABI macro, since it isn't backwards compatible (i.e., clients built against the new libc++ headers wouldn't be able to run against an older libc++ library). Reviewers: mclow.lists, EricWF Subscribers: mgorny, cfe-commits Differential Revision: https://reviews.llvm.org/D27387 llvm-svn: 298937
* Change test coverage generation to use llvm-cov instead of gcov.Eric Fiselier2017-03-111-6/+5
| | | | | | | | | | | | | Clang doesn't produce gcov compatible coverage files. This causes lcov to break because it uses gcov by default. This patch switches lcov to use llvm-cov as the gcov-tool. Unfortunatly llvm-cov doesn't provide a gcov like interface by default so it won't work with lcov. However `llvm-cov gcov` does. For this reason we generate 'llvm-cov-wrapper' script that always passes the gcov flag. llvm-svn: 297553
* Start libc++ python cleanup and consolidation.Eric Fiselier2017-02-091-1/+1
| | | | | | | | | Libc++ frequently creates and uses utilities written in python. Currently there are python modules under both libcxx/test and libcxx/util. My goal with these changes is to consolidate them into a single package under libcxx/utils/libcxx. llvm-svn: 294644
* [libcxx][CMake] Support in-tree libunwind when building as part of runtimesPetr Hosek2017-02-091-2/+2
| | | | | | | | | | | When building as part of runtimes, there is no predefined order in which the runtimes are loaded, so the targets from other projects might not be available. We need to rely on HAVE_<name> variables instead in that case. Differential Revision: https://reviews.llvm.org/D29575 llvm-svn: 294553
* Reland "[CMake][libcxx] Do not rely on the existence of c++abi or unwind ↵Petr Hosek2017-01-161-2/+5
| | | | | | | | targets" This relands commit r291727. llvm-svn: 292085
* [libc++][CMake] Use debug MSVC runtimes when libc++ is built in debug modeEric Fiselier2017-01-141-3/+10
| | | | | | | | | | | | Summary: This patch allows libc++ to be built against the debug MSVC runtimes instead of just the release ones. Reviewers: rnk, majnemer, compnerd, smeenai Subscribers: mgorny, cfe-commits Differential Revision: https://reviews.llvm.org/D28725 llvm-svn: 292006
* [libc++] [CMake] Link with /nodefaultlibs on WindowsEric Fiselier2017-01-141-0/+11
| | | | | | | | | | | | | | | | Summary: This patch attempts to fix the libc++ build/link so that it doesn't use an default C++ libraries on Windows. This is needed to prevent linking to MSVC's STL library. Additionally this patch changes libc++ so that it is always linked with the non-debug DLL's (e.g. `/MD`). This is needed so that the test suite can correctly link the same libraries without needing to know which configuration `c++.dll` was linked with. Reviewers: compnerd, rnk, majnemer, kimgr, awson, halyavin, smeenai Subscribers: cfe-commits, mgorny Differential Revision: https://reviews.llvm.org/D28441 llvm-svn: 292001
* Revert "[CMake][libcxx] Do not rely on the existence of c++abi or unwind ↵Petr Hosek2017-01-111-5/+2
| | | | | | | | targets" This reverts commit 94fc5a96f58071703d81d14690094dcd266a5e17. llvm-svn: 291727
* [CMake][libcxx] Do not rely on the existence of c++abi or unwind targetsPetr Hosek2017-01-111-2/+5
| | | | | | | | | | | There is no guaranteed order in which CMake files for individual runtimes are invoked and therefore we cannot rely on existence of targets defined in other runtimes. Use the new HAVE_<name> options instead in those cases. Differential Revision: https://reviews.llvm.org/D28391 llvm-svn: 291632
* [libc++] Cleanup and document <__threading_support>Eric Fiselier2017-01-061-1/+1
| | | | | | | | | | | | | | | 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
* build: use the platform dependent library prefix/suffixSaleem Abdulrasool2017-01-041-1/+2
| | | | | | | | Use the cmake variables to get the platform dependent values for the static library prefix and suffix, which can be different from the Unix preference for "lib", ".a" (e.g. Windows uses "", ".lib" respectively). llvm-svn: 290939
* build: use more portable spelling for flagSaleem Abdulrasool2017-01-041-2/+3
| | | | | | | Use `CMAKE_LIBRARY_PATH_FLAG` instead of hard-coding it to -L. This silences a warning with cl which expects `/LIBPATH` instead. llvm-svn: 290938
* Recommit r290839 - Fix configuring and building libc++ w/o an ABI library.Eric Fiselier2017-01-031-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch re-commits a previous attempt to support building libc++ w/o an ABI library. That patch was originally reverted because: 1) It forgot to teach the test suite about "default" ABI libraries. 2) Some LLVM builders don't clear the CMake cache between builds. The previous patch caused those builders to fail since their old cache entry for LIBCXX_CXX_ABI="" is no longer valid. The updated patch addresses both issues. It works around (2) by adding a hack to force the builders to update their cache entries. The hack will be removed shortly once all LLVM builders have run. Original commit message ----------------------- Typically libc++ uses libc++abi or libcxxrt to provide the ABI and runtime bits of the C++ STL. However we also support building w/o an ABI library entirely. This patch fixes building libc++ w/o an ABI library (and incorporates the `~type_info()` fix in D28211). The main changes in this patch are: 1) Add `-DLIBCXX_CXX_ABI=default` instead of using the empty string to mean "default". 2) Fix CMake bits which treated "none" as "default" on OS X. 3) Teach the source files to respect `-D_LIBCPP_BUILDING_HAS_NO_ABI_LIBRARY`. 4) Define ~type_info() when _LIBCPP_BUILDING_HAS_NO_ABI_LIBRARY is defined. Unfortunately this patch doesn't help clean up the macro mess that we use to configure for different ABI libraries. llvm-svn: 290849
* Revert r290839 - Fix configuring and building libc++ w/o an ABI libraryEric Fiselier2017-01-021-1/+1
| | | | llvm-svn: 290841
* Fix configuring and building libc++ w/o an ABI library.Eric Fiselier2017-01-021-1/+1
| | | | | | | | | | | | | | | | | | | Typically libc++ uses libc++abi or libcxxrt to provide the ABI and runtime bits of the C++ STL. However we also support building w/o an ABI library entirely. This patch fixes building libc++ w/o an ABI library (and incorporates the `~type_info()` fix in D28211). The main changes in this patch are: 1) Add `-DLIBCXX_CXX_ABI=default` instead of using the empty string to mean "default". 2) Fix CMake bits which treated "none" as "default" on OS X. 3) Teach the source files to respect `-D_LIBCPP_BUILDING_HAS_NO_ABI_LIBRARY`. 4) Define ~type_info() when _LIBCPP_BUILDING_HAS_NO_ABI_LIBRARY is defined. Unfortunately this patch doesn't help clean up the macro mess that we use to configure for different ABI libraries. llvm-svn: 290839
* build: tweak macros for Windows buildSaleem Abdulrasool2017-01-021-0/+22
| | | | | | | | | | | Move the windows specific macro definitions for compiling c++ into the target. Add a number of newer options that are necessary to properly build libc++ for windows. This ensures that we do not accidentally autolink msvcprt (Microsoft's C++ runtime library), do not define linker pragmas which are msvcprt specific, and do not accidentally encode the incorrect version of the msvc compatibility version. llvm-svn: 290837
* build: make cross-compiling to Windows work on LinuxSaleem Abdulrasool2017-01-021-0/+7
| | | | | | | | | Disable the manifest bundling on Windows when cross-compiling on not-Windows. With this, it is possible to execute the link command from CMake which will use cmake to invoke the manifest tool to generate a manifest and pass that to the linker. llvm-svn: 290836
* Make LIBCXX_ENABLE_STATIC_ABI_LIBRARY merge libc++.a and libc++abi.aEric Fiselier2016-11-181-0/+22
| | | | llvm-svn: 287373
* [solaris] Convert the support library to C++ to fix -std=c++11 buildMichal Gorny2016-10-181-1/+1
| | | | | | | | | | | Convert the Solaris xlocale.c compatibility library from plain C to C++ in order to fix the build failures caused by the addition of -std=c++11 to LIBCXX_COMPILE_FLAGS. The additional flag got propagated to the C file, resulting in error with strict compilers. Differential Revision: https://reviews.llvm.org/D25431 llvm-svn: 284494
* Remove dead CMake targetEric Fiselier2016-10-141-4/+0
| | | | llvm-svn: 284216
* Fix CMake configuration error and add ABI lists for OS X.Eric Fiselier2016-10-141-1/+1
| | | | | | | | | | | | The primary reason for this patch is to add the OS X ABI lists for 3.9 and ToT. However while working on that I discovered that we incorrectly exported the libc++abi symbols. Previously we had chosen the wrong CMake configuration path and that caused us to re-export the c++abi binary instead of using the symbol lists. llvm-svn: 284188
* Fix linker script generation for in-tree buildsEric Fiselier2016-10-091-21/+26
| | | | llvm-svn: 283700
* [CMake] Fix in-tree libcxxabi build support after r283659Hal Finkel2016-10-091-5/+10
| | | | | | | | | | | r283659 changed the argument to gen_link_script.py from SCRIPT_ABI_LIBNAME to LIBCXX_LIBRARIES_PUBLIC, assuming that all of the items in the LIBCXX_LIBRARIES_PUBLIC list were library names. This is not right, however, for in-tree libcxxabi builds, we might have the target name in this list. There was special logic to fixup SCRIPT_ABI_LIBNAME for this situation; change it to apply a similar fixup for LIBCXX_LIBRARIES_PUBLIC. llvm-svn: 283684
* [cmake] Split linked libraries into private & public, for linker scriptMichal Gorny2016-10-081-7/+24
| | | | | | | | | | | | | | | Introduce LIBCXX_LIBRARIES_PUBLIC in addition to LIBCXX_LIBRARIES that holds 'public' interface libraries -- that is, libraries that both libc++ links to and programs linked against it need to link to. Currently this includes the ABI library and optionally -lunwind (when LIBCXXABI_USE_LLVM_UNWINDER is on). The libraries are included in the linker script, in order to make it possible to link C++ programs using clang with compiler-rt runtime out-of-the-box. Differential Revision: https://reviews.llvm.org/D25008 llvm-svn: 283659
* [libcxx] Allow sanitizing libcxx with ASan+UBSan simultaneouslyKuba Brecka2016-09-151-1/+3
| | | | | | | | Allow building with LLVM_USE_SANITIZER=“Address;Undefined” (and “Undefined;Address”). Differential Revision: https://reviews.llvm.org/D24569 llvm-svn: 281603
* [libcxx] Enable building and testing of libcxx with ThreadSanitizer on OS XKuba Brecka2016-09-141-0/+2
| | | | | | | | This patch enables building and testing libcxx under ThreadSanitizer on OS X. CMake builds that have -DLLVM_USE_SANITIZER=Thread will automatically build libcxx with -fsanitize=thread and testing via lit then runs under TSan. Differential Revision: https://reviews.llvm.org/D24297 llvm-svn: 281475
* [libcxx] Introduce an externally-threaded libc++ variant.Asiri Rathnayake2016-09-111-0/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* build: don't add -fPIC on WindowsSaleem Abdulrasool2016-09-011-1/+3
| | | | | | | | | `-fPIC` doesn't make much sense for Windows, since Windows DLLs aren't compiled position independent and are instead relocated at runtime. Patch by Shoaib Meenai! llvm-svn: 280413
* Fix syntax error in recent CMake change.Eric Fiselier2016-08-301-1/+1
| | | | llvm-svn: 280042
* Fix PR28831 - Bad logic around CMAKE_OSX_SYSROOT and CMAKE_OSX_ARCHITECTURES.Eric Fiselier2016-08-301-2/+2
| | | | | | | See https://llvm.org/bugs/show_bug.cgi?id=28831 for more information about the changes. llvm-svn: 280037
* [CMake] Be more consistent about naming targets and componentsChris Bieneman2016-08-241-5/+6
| | | | | | | | | | | | | | | Summary: The point of this patch is to have a consistent convention for naming build, check and install targets so that the targets can be constructed from the project name. This change renames a bunch of CMake components and targets from libcxx to cxx. For each renamed target I've added a convenience target that matches the old target name and depends on the new target. This will preserve function of the old targets so that the change doesn't break the world. We can evaluate if it is worth removing the extra targets later. Reviewers: EricWF Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D23699 llvm-svn: 279675
* Allow building both shared and static libraryPetr Hosek2016-08-081-22/+49
| | | | | | | | | This change allows building both shared and static version of libc++ in a single build, sharing object files between both versions. Differential Revision: https://reviews.llvm.org/D23232 llvm-svn: 278068
* Rework libatomic handling in CMake and LIT.Eric Fiselier2016-07-181-1/+1
| | | | | | | | | | | | | | | This patch updates the way libc++ handles checking for libatomic, in part to prepare for https://reviews.llvm.org/D22073. Changes: * 'LIBCXX_HAS_ATOMIC_LIB' is now set whenever libatomic is available even libc++ doesn't need to manually link it. * 'LIBCXX_HAVE_CXX_ATOMICS_WITH_LIB' is now used to detect when libatomic needs to be manually linked. * 'LIBCXX_HAS_ATOMIC_LIB' now adds 'libatomic' as a available feature in the test suite. llvm-svn: 275759
* Add Filesystem TS -- CompleteEric Fiselier2016-06-171-1/+4
| | | | | | | | | | | | | | Add the completed std::experimental::filesystem implementation and tests. The implementation supports C++11 or newer. The TS is built as part of 'libc++experimental.a'. Users of the TS need to manually link this library. Building and testing the TS can be disabled using the CMake option '-DLIBCXX_ENABLE_FILESYSTEM=OFF'. Currently 'libc++experimental.a' is not installed by default. To turn on the installation of the library use '-DLIBCXX_INSTALL_EXPERIMENTAL_LIBRARY=ON'. llvm-svn: 273034
* Automatically detect export lists for OS X.Eric Fiselier2016-06-141-1/+15
| | | | | | | | | | | | | | | | | | Summary: Libc++ reexports symbols from the system libc++abi using -reexport_symbols_list. This can cause a linker failure if the list contains symbols not defined in the system libc++abi. This patch attempts to detect the OS X version and use it to determine the correct symbol list. It's my understanding that `lib/libc++abi2.exp` should be used on 10.9 and greater. Otherwise 'lib/libc++abi.exp' should be used This fixes PR25666 (https://llvm.org/bugs/show_bug.cgi?id=25666) Reviewers: mclow.lists, bcraig, dexonsmith, EricWF Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D20772 llvm-svn: 272723
* [libcxx] Prefer C++14 over C++11 when building libc++experimental.Eric Fiselier2016-05-101-1/+7
| | | | | | | | | | | | | | | | | | Summary: Currently libc++experimental builds with C++11. This patch changes that to C++14 when supported by the compiler. Although nothing currently requires C++14 the upcoming <experimental/memory_resource> implementation would benefit from it. [1] Note that libc++.so continues to build with C++11 and is unaffected by this change. [1] <experimental/memory_resource> provides global resources which must exist for the entire lifetime of the program. In order to ensure that a global resource can be used during program termination there destructors must never be invoked. The only way to do this, while also allowing "constant initialization", is to use a C++14 union. Reviewers: mclow.lists Subscribers: pete, cfe-commits Differential Revision: http://reviews.llvm.org/D19992 llvm-svn: 269070
* Create new library 'libc++experimental.a' for packaging TS symbols.Eric Fiselier2016-05-031-2/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Out-of-line symbols for <experimental/...> headers are not ABI or API stable and cannot live in the 'libc++.dylib'. Currently they have nowhere to live. I would like to add a new library target `libc++experimental.a` to fix this. Previously I had suggested different libraries for different TS's (`libc++filesystem.a`, 'libc++LFTS.a`, ect). I no longer think this is the right approach. Instead `c++experimental` will hold *all* TS implementations as a single monolithic library. I see two main benefits to this: 1. Users only have to know about and manually link one library. 2. It makes it easy to implement TS's with one or two out-of-line symbols. (Ex. PMRs) `c++experimental` provides NO ABI compatibility. Symbols can freely be added/removed/changed without concern for ABI stability. I will add documentation for this after landing this patch (but before adding anything to it). `c++experimental` only builds as a static library. By default CMake will build/test this library but will *NOT* install it. This patch adds the CMake and LIT logic needed to build/test the new library. Once this lands I plan on using it to implement parts of `<experimental/memory_resource>`. Reviewers: mclow.lists Subscribers: cfe-commits, theraven, krememek, dexonsmith, bcraig, beanz, danalbert Differential Revision: http://reviews.llvm.org/D19856 llvm-svn: 268443
OpenPOWER on IntegriCloud