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

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

958 lines
42 KiB
CMake
Raw Normal View History

[libc++] Update a bad documentation link
2020-03-25 09:33:42 +08:00
# See https://libcxx.llvm.org/docs/BuildingLibcxx.html for instructions on how
# to build libcxx with CMake.
test commit llvm-svn: 302122
2017-05-04 14:28:34 +08:00
Enforce that libc++ and libc++abi are built in a monorepo layout We will soon start removing technical debt and sharing code between the two directories, so this first step is meant to discover potential places where the libraries are built outside of a monorepo layout. I imagine this could happen as a remnant of the pre-monorepo setup. This was discussed on the libcxx-dev mailing list and we got overall consensus on the direction. All consumers of libc++ and libc++abi should already be doing so through the monorepo, however it is possible that we catch some stragglers with this patch, in which case it may need to be reverted temporarily. Differential Revision: https://reviews.llvm.org/D76102
2020-03-13 06:01:20 +08:00
if (NOT IS_DIRECTORY "${CMAKE_CURRENT_LIST_DIR}/../libcxxabi")
message(FATAL_ERROR "libc++ now requires being built in a monorepo layout with libcxxabi available")
endif()
Add CMake build and fix major Linux blockers. llvm-svn: 121510
2010-12-11 03:47:54 +08:00
#===============================================================================
# Setup Project
#===============================================================================
[CMake] Bump CMake minimum version to 3.13.4 This upgrade should be friction-less because we've already been ensuring that CMake >= 3.13.4 is used. This is part of the effort discussed on llvm-dev here: http://lists.llvm.org/pipermail/llvm-dev/2020-April/140578.html Differential Revision: https://reviews.llvm.org/D78648
2020-04-22 23:15:05 +08:00
cmake_minimum_required(VERSION 3.13.4)
Add CMake build and fix major Linux blockers. llvm-svn: 121510
2010-12-11 03:47:54 +08:00
[CMake] Remove dead code setting policies to NEW cmake_minimum_required(VERSION) calls cmake_policy(VERSION), which sets all policies up to VERSION to NEW. LLVM started requiring CMake 3.13 last year, so we can remove a bunch of code setting policies prior to 3.13 to NEW as it no longer has any effect. Reviewed By: phosek, #libunwind, #libc, #libc_abi, ldionne Differential Revision: https://reviews.llvm.org/D94374
2021-01-10 20:11:35 +08:00
set(CMAKE_BUILD_WITH_INSTALL_NAME_DIR ON)
Reapply working parts of CMake cleanup. This patch adds the working parts of r243503. The difference with this patch is that it doesn't include the HandleLLVMOptions.cmake file. llvm-svn: 243698
2015-07-31 06:30:34 +08:00
Add CMake build and fix major Linux blockers. llvm-svn: 121510
2010-12-11 03:47:54 +08:00
# Add path for custom modules
set(CMAKE_MODULE_PATH
"${CMAKE_CURRENT_SOURCE_DIR}/cmake"
"${CMAKE_CURRENT_SOURCE_DIR}/cmake/Modules"
Revert r256606 due to compiler-rt sanitizer bot failures llvm-svn: 256614
2015-12-30 11:39:03 +08:00
${CMAKE_MODULE_PATH}
Add CMake build and fix major Linux blockers. llvm-svn: 121510
2010-12-11 03:47:54 +08:00
)
[libc++] Set CMAKE_FOLDER. NFC. * This variable populates the default value of FOLDER target property. It is used in some IDE's (e.g. MSVC) to group different targets together.
2021-01-25 16:50:03 +08:00
set(CMAKE_FOLDER "libc++")
[libcxxabi,libunwind] support running tests in standalone mode Remove check for standalone and shared library mode in libcxxabi to allow including tests in said mode. This check prevented running the tests in standalone mode with static libraries, which is the case for baremetal targets. Fix check-unwind target trying to use a non-existent llvm-lit executable in standalone mode. Copy the HandleOutOfTreeLLVM logic from libcxxabi to libunwind in order to make the tests work in standalone mode. Reviewed By: ldionne, #libc_abi, #libc Differential Revision: https://reviews.llvm.org/D86540
2020-08-24 17:01:05 +08:00
set(LIBCXX_SOURCE_DIR ${CMAKE_CURRENT_SOURCE_DIR})
set(LIBCXX_BINARY_DIR ${CMAKE_CURRENT_BINARY_DIR})
set(LIBCXX_BINARY_INCLUDE_DIR "${LIBCXX_BINARY_DIR}/include/c++build")
[compiler-rt] Build custom libcxx with libcxxabi This changes add_custom_libcxx to also build libcxxabi and merges the two into a static and hermetic library. There are multiple advantages: 1) The resulting libFuzzer doesn't expose C++ internals and looks like a plain C library. 2) We don't have to manually link in libstdc++ to provide cxxabi. 3) The sanitizer tests cannot interfere with an installed version of libc++.so in LD_LIBRARY_PATH. Differential Revision: https://reviews.llvm.org/D58013 llvm-svn: 354212
2019-02-17 20:16:20 +08:00
if (CMAKE_SOURCE_DIR STREQUAL CMAKE_CURRENT_SOURCE_DIR OR LIBCXX_STANDALONE_BUILD)
build: silence warnings in in-tree build Avoid the developer warnings from cmake when configuring libc++ as part of the LLVM layout. Setup the custom macro paths earlier to re-use the detection logic prior to setting the project properties. llvm-svn: 260071
2016-02-08 11:50:18 +08:00
project(libcxx CXX C)
set(PACKAGE_NAME libcxx)
Bump the trunk major version to 13 and clear the release notes.
2021-01-27 11:37:08 +08:00
set(PACKAGE_VERSION 13.0.0git)
build: silence warnings in in-tree build Avoid the developer warnings from cmake when configuring libc++ as part of the LLVM layout. Setup the custom macro paths earlier to re-use the detection logic prior to setting the project properties. llvm-svn: 260071
2016-02-08 11:50:18 +08:00
set(PACKAGE_STRING "${PACKAGE_NAME} ${PACKAGE_VERSION}")
set(PACKAGE_BUGREPORT "llvm-bugs@lists.llvm.org")
Add check-cxx-abilist target when supported. This patch adds a `check-cxx-abilist` target which verifies the libc++.so ABI when the current build configuration matches the configuration used to generate the ABI lists. In order to make this change `HandleOutOfTreeLLVM.cmake` needed to be modified to include `LLVMConfig.cmake` so that `TARGET_TRIPLE` is defined. Hopefully the changes needed to accommodate this won't break existing build configurations. llvm-svn: 286789
2016-11-14 10:43:12 +08:00
[libcxxabi,libunwind] support running tests in standalone mode Remove check for standalone and shared library mode in libcxxabi to allow including tests in said mode. This check prevented running the tests in standalone mode with static libraries, which is the case for baremetal targets. Fix check-unwind target trying to use a non-existent llvm-lit executable in standalone mode. Copy the HandleOutOfTreeLLVM logic from libcxxabi to libunwind in order to make the tests work in standalone mode. Reviewed By: ldionne, #libc_abi, #libc Differential Revision: https://reviews.llvm.org/D86540
2020-08-24 17:01:05 +08:00
# In a standalone build, we don't have llvm to automatically generate the
# llvm-lit script for us. So we need to provide an explicit directory that
# the configurator should write the script into.
set(LIBCXX_STANDALONE_BUILD 1)
set(LLVM_LIT_OUTPUT_DIR "${LIBCXX_BINARY_DIR}/bin")
Add check-cxx-abilist target when supported. This patch adds a `check-cxx-abilist` target which verifies the libc++.so ABI when the current build configuration matches the configuration used to generate the ABI lists. In order to make this change `HandleOutOfTreeLLVM.cmake` needed to be modified to include `LLVMConfig.cmake` so that `TARGET_TRIPLE` is defined. Hopefully the changes needed to accommodate this won't break existing build configurations. llvm-svn: 286789
2016-11-14 10:43:12 +08:00
# Find the LLVM sources and simulate LLVM CMake options.
include(HandleOutOfTreeLLVM)
CMakeLists.txt cleanups: synchronize version with rest of LLVM, consistent spacing. Differential revision: https://reviews.llvm.org/D23091 llvm-svn: 278032
2016-08-09 02:01:50 +08:00
endif()
build: silence warnings in in-tree build Avoid the developer warnings from cmake when configuring libc++ as part of the LLVM layout. Setup the custom macro paths earlier to re-use the detection logic prior to setting the project properties. llvm-svn: 260071
2016-02-08 11:50:18 +08:00
Reland "[CMake][libcxx] Move Python check to main CMake file" This relands commit r291728. llvm-svn: 292084
2017-01-16 08:33:07 +08:00
if (LIBCXX_STANDALONE_BUILD)
[CMake] Remove dead FindPythonInterp code LLVM has bumped the minimum required CMake version to 3.13.4, so this has become dead code. Reviewed By: #libc, ldionne Differential Revision: https://reviews.llvm.org/D87189
2020-09-05 22:52:23 +08:00
find_package(Python3 COMPONENTS Interpreter)
if(NOT Python3_Interpreter_FOUND)
message(WARNING "Python3 not found, using python2 as a fallback")
find_package(Python2 COMPONENTS Interpreter REQUIRED)
if(Python2_VERSION VERSION_LESS 2.7)
message(SEND_ERROR "Python 2.7 or newer is required")
build: update libc++ as there are some bots with integrated build Some of the builders are building with C++ in the unified build. Merge this without review to try to restore the builder.
2020-04-29 03:50:12 +08:00
endif()
[CMake] Remove dead FindPythonInterp code LLVM has bumped the minimum required CMake version to 3.13.4, so this has become dead code. Reviewed By: #libc, ldionne Differential Revision: https://reviews.llvm.org/D87189
2020-09-05 22:52:23 +08:00
# Treat python2 as python3
add_executable(Python3::Interpreter IMPORTED)
set_target_properties(Python3::Interpreter PROPERTIES
IMPORTED_LOCATION ${Python2_EXECUTABLE})
set(Python3_EXECUTABLE ${Python2_EXECUTABLE})
Reland "[CMake][libcxx] Move Python check to main CMake file" This relands commit r291728. llvm-svn: 292084
2017-01-16 08:33:07 +08:00
endif()
endif()
build: silence warnings in in-tree build Avoid the developer warnings from cmake when configuring libc++ as part of the LLVM layout. Setup the custom macro paths earlier to re-use the detection logic prior to setting the project properties. llvm-svn: 260071
2016-02-08 11:50:18 +08:00
# Require out of source build.
include(MacroEnsureOutOfSourceBuild)
MACRO_ENSURE_OUT_OF_SOURCE_BUILD(
"${PROJECT_NAME} requires an out of source build. Please create a separate
build directory and run 'cmake /path/to/${PROJECT_NAME} [options]' there."
)
Remove even more warnings from clang-cl build llvm-svn: 343434
2018-10-01 09:31:23 +08:00
if("${CMAKE_CXX_COMPILER_ID}" STREQUAL "Clang" AND "${CMAKE_CXX_SIMULATE_ID}" STREQUAL "MSVC")
message(STATUS "Configuring for clang-cl")
set(LIBCXX_TARGETING_CLANG_CL ON)
endif()
build: silence warnings in in-tree build Avoid the developer warnings from cmake when configuring libc++ as part of the LLVM layout. Setup the custom macro paths earlier to re-use the detection logic prior to setting the project properties. llvm-svn: 260071
2016-02-08 11:50:18 +08:00
[libc++] [CMake] Link with /nodefaultlibs on Windows 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
2017-01-14 14:06:47 +08:00
if (MSVC)
set(LIBCXX_TARGETING_MSVC ON)
Attempt to unbreak Windows configuration. Although libc++ doesn't yet support Windows we still have Windows builders to track our progress. Currently the clang-cl configuration seems broken because it doesn't support -std=c++11 and instead requires /std:c++11. This patch attempts to fix this. llvm-svn: 343431
2018-10-01 09:00:11 +08:00
message(STATUS "Configuring for MSVC")
[libc++] [CMake] Link with /nodefaultlibs on Windows 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
2017-01-14 14:06:47 +08:00
else()
set(LIBCXX_TARGETING_MSVC OFF)
endif()
Add CMake build and fix major Linux blockers. llvm-svn: 121510
2010-12-11 03:47:54 +08:00
#===============================================================================
# Setup CMake Options
#===============================================================================
Enable installation of libc++experimental by default. When libc++experimental was originally created it was empty and therefore there was no reason to install it. Now that the library contains <experimental/memory_resource> and <experimental/filesystem> there is a good reason to install it. Specifically this patch enables the installation whenever LIBCXX_INSTALL_LIBRARY is true and LIBCPP_ENABLE_EXPERIMENTAL_LIBRARY is true. llvm-svn: 280773
2016-09-07 09:15:10 +08:00
include(CMakeDependentOption)
Change test coverage generation to use llvm-cov instead of gcov. 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
2017-03-11 11:24:18 +08:00
include(HandleCompilerRT)
Add CMake build and fix major Linux blockers. llvm-svn: 121510
2010-12-11 03:47:54 +08:00
Reapply working parts of CMake cleanup. This patch adds the working parts of r243503. The difference with this patch is that it doesn't include the HandleLLVMOptions.cmake file. llvm-svn: 243698
2015-07-31 06:30:34 +08:00
# Basic options ---------------------------------------------------------------
Recommit [libcxx] Never use <cassert> within libc++ It is my opinion that libc++ should never use `<cassert>`, including in the `dylib`. This patch remove all uses of `assert` from within libc++ and replaces most of them with `_LIBCPP_ASSERT` instead. Additionally this patch turn `LIBCXX_ENABLE_ASSERTIONS` off by default, because the standard library should not be aborting user programs unless explicitly asked to. llvm-svn: 294107
2017-02-05 07:22:28 +08:00
option(LIBCXX_ENABLE_ASSERTIONS "Enable assertions independent of build mode." OFF)
Revert recent CMake changes again due to failing compiler-rt builds llvm-svn: 243593
2015-07-30 07:46:55 +08:00
option(LIBCXX_ENABLE_SHARED "Build libc++ as a shared library." ON)
Allow building both shared and static library 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
2016-08-09 06:57:25 +08:00
option(LIBCXX_ENABLE_STATIC "Build libc++ as a static library." ON)
Create new library 'libc++experimental.a' for packaging TS symbols. 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
2016-05-04 05:30:18 +08:00
option(LIBCXX_ENABLE_EXPERIMENTAL_LIBRARY "Build libc++experimental.a" ON)
Allow disabling of filesystem library. Summary: Filesystem doesn't work on Windows, so we need a mechanism to turn it off for the time being. Reviewers: ldionne, serge-sans-paille, EricWF Reviewed By: EricWF Subscribers: mstorsjo, mgorny, christof, jdoerfert, libcxx-commits Differential Revision: https://reviews.llvm.org/D59619 llvm-svn: 356633
2019-03-21 08:04:31 +08:00
set(ENABLE_FILESYSTEM_DEFAULT ON)
[libcxx] Enable filesystem by default for mingw targets This feature can be built successfully for windows now. However, the helper functions for __int128_t aren't available in MSVC configurations, so don't enable it by default there yet. (See https://reviews.llvm.org/D91139 for discussion on how to proceed with things in MSVC environments.) Differential Revision: https://reviews.llvm.org/D97075
2020-11-05 06:13:22 +08:00
if (WIN32 AND NOT MINGW)
# Filesystem is buildable for windows, but it requires __int128 helper
# functions, that currently are provided by libgcc or compiler_rt builtins.
# These are available in MinGW environments, but not currently in MSVC
# environments.
Allow disabling of filesystem library. Summary: Filesystem doesn't work on Windows, so we need a mechanism to turn it off for the time being. Reviewers: ldionne, serge-sans-paille, EricWF Reviewed By: EricWF Subscribers: mstorsjo, mgorny, christof, jdoerfert, libcxx-commits Differential Revision: https://reviews.llvm.org/D59619 llvm-svn: 356633
2019-03-21 08:04:31 +08:00
set(ENABLE_FILESYSTEM_DEFAULT OFF)
endif()
option(LIBCXX_ENABLE_FILESYSTEM "Build filesystem as part of the main libc++ library"
${ENABLE_FILESYSTEM_DEFAULT})
Reapply working parts of CMake cleanup. This patch adds the working parts of r243503. The difference with this patch is that it doesn't include the HandleLLVMOptions.cmake file. llvm-svn: 243698
2015-07-31 06:30:34 +08:00
option(LIBCXX_INCLUDE_TESTS "Build the libc++ tests." ${LLVM_INCLUDE_TESTS})
[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
option(LIBCXX_ENABLE_PARALLEL_ALGORITHMS "Enable the parallel algorithms library. This requires the PSTL to be available." OFF)
[libc++] Fixup a missing occurrence of LIBCXX_ENABLE_DEBUG_MODE
2020-10-10 02:40:47 +08:00
option(LIBCXX_ENABLE_DEBUG_MODE_SUPPORT
[libc++] Add a CMake option to control whether the debug mode is supported Some libc++ builds may want to disable support for the debug mode, for example to reduce code size or because the current implementation of the debug mode requires a global map. This commit adds the LIBCXX_ENABLE_DEBUG_MODE CMake option and ties it into the test suite. It also adds a CI job to test this configuration going forward. Differential Revision: https://reviews.llvm.org/D88923
2020-10-07 04:46:58 +08:00
"Whether to include support for libc++'s debugging mode in the library.
By default, this is turned on. If you turn it off and try to enable the
debug mode when compiling a program against libc++, it will fail to link
since the required support isn't provided in the library." ON)
[libc++] Allow building libc++ on platforms without a random device Some platforms, like several embedded platforms, do not provide a source of randomness through a random device. This commit makes it possible to build and test libc++ for such platforms, i.e. without std::random_device. Surprisingly, the only functionality that doesn't work on such platforms is std::random_device itself -- everything else in <random> still works, one just has to find alternative ways to seed the PRNGs.
2020-10-15 22:32:09 +08:00
option(LIBCXX_ENABLE_RANDOM_DEVICE
"Whether to include support for std::random_device in the library. Disabling
this can be useful when building the library for platforms that don't have
a source of randomness, such as some embedded platforms. When this is not
supported, most of <random> will still be available, but std::random_device
will not." ON)
[libc++] Add a libc++ configuration that does not support localization When porting libc++ to embedded systems, it can be useful to drop support for localization, which these systems don't implement or care about. Differential Revision: https://reviews.llvm.org/D90072
2020-10-10 03:31:05 +08:00
option(LIBCXX_ENABLE_LOCALIZATION
"Whether to include support for localization in the library. Disabling
localization can be useful when porting to platforms that don't support
the C locale API (e.g. embedded). When localization is not supported,
several parts of the library will be disabled: <iostream>, <regex>, <locale>
will be completely unusable, and other parts may be only partly available." ON)
[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
option(LIBCXX_ENABLE_VENDOR_AVAILABILITY_ANNOTATIONS
"Whether to turn on vendor availability annotations on declarations that depend
on definitions in a shared library. By default, we assume that we're not building
libc++ for any specific vendor, and we disable those annotations. Vendors wishing
to provide compile-time errors when using features unavailable on some version of
the shared library they shipped should turn this on and see `include/__availability`
for more details." OFF)
[libc++] Move the default site config template alongside other config files
2020-08-30 05:13:02 +08:00
set(LIBCXX_TEST_CONFIG "${CMAKE_CURRENT_SOURCE_DIR}/test/configs/legacy.cfg.in" CACHE STRING
[libc++] Allow overriding the cached value of LIBCXX_TEST_CONFIG
2020-09-08 23:29:32 +08:00
"The Lit testing configuration to use when running the tests.")
[runtimes] Allow passing Lit parameters through CMake This allows passing parameters to the test suites without using LLVM_LIT_ARGS. The problem is that we sometimes want to set some Lit arguments on the CMake command line, but the Lit parameters in a CMake cache file. If the only knob to do that is LLVM_LIT_ARGS, the command-line entry overrides the cache one, and the parameters set by the cache are ignored. This fixes a current issue with the build bots that they completely ignore the 'std' param set by Lit, because other Lit arguments are provided via LLVM_LIT_ARGS on the CMake command-line.
2020-07-09 23:54:09 +08:00
set(LIBCXX_TEST_PARAMS "" CACHE STRING
"A list of parameters to run the Lit test suite with.")
Add start of filesystem benchmarks llvm-svn: 285524
2016-10-31 06:53:00 +08:00
# Benchmark options -----------------------------------------------------------
[NFC][libc++] Fix typo in the description of LIBCXX_INCLUDE_BENCHMARKS llvm-svn: 342822
2018-09-23 05:30:12 +08:00
option(LIBCXX_INCLUDE_BENCHMARKS "Build the libc++ benchmarks and their dependencies" ON)
Rename cxx-benchmark-unittests target and convert to LIT. This patch renames the cxx-benchmark-unittests to check-cxx-benchmarks and converts the target to use LIT in order to make the tests run faster and provide better output. In particular this runs each benchmark in a suite one by one, allowing more parallelism while ensuring output isn't garbage with multiple threads. Additionally, it adds the CMake flag '-DLIBCXX_BENCHMARK_TEST_ARGS=<list>' to specify what options are passed when running the benchmarks. llvm-svn: 346888
2018-11-15 04:38:46 +08:00
set(LIBCXX_BENCHMARK_TEST_ARGS_DEFAULT --benchmark_min_time=0.01)
set(LIBCXX_BENCHMARK_TEST_ARGS "${LIBCXX_BENCHMARK_TEST_ARGS_DEFAULT}" CACHE STRING
"Arguments to pass when running the benchmarks using check-cxx-benchmarks")
Add start of filesystem benchmarks llvm-svn: 285524
2016-10-31 06:53:00 +08:00
set(LIBCXX_BENCHMARK_NATIVE_STDLIB "" CACHE STRING
"Build the benchmarks against the specified native STL.
The value must be one of libc++/libstdc++")
set(LIBCXX_BENCHMARK_NATIVE_GCC_TOOLCHAIN "" CACHE STRING
"Use alternate GCC toolchain when building the native benchmarks")
if (LIBCXX_BENCHMARK_NATIVE_STDLIB)
if (NOT (LIBCXX_BENCHMARK_NATIVE_STDLIB STREQUAL "libc++"
OR LIBCXX_BENCHMARK_NATIVE_STDLIB STREQUAL "libstdc++"))
message(FATAL_ERROR "Invalid value for LIBCXX_BENCHMARK_NATIVE_STDLIB: "
"'${LIBCXX_BENCHMARK_NATIVE_STDLIB}'")
endif()
endif()
[libcxx] Add new Sphinx documentation Summary: This patch adds Sphinx based documentation to libc++. The goal is to make it easier to write documentation for libc++ since writing new documentation in HTML is cumbersome. This patch rewrites the main page for libc++ along with the instructions for using, building and testing libc++. The built documentation can be found and reviewed here: http://efcs.ca/libcxx-docs In order to build the sphinx documentation you need to specify the cmake options `-DLLVM_ENABLE_SPHINX=ON -DLIBCXX_INCLUDE_DOCS=ON`. This will add the makefile rule `docs-libcxx-html`. Reviewers: chandlerc, mclow.lists, danalbert, jroelofs Subscribers: silvas, cfe-commits Differential Revision: http://reviews.llvm.org/D12129 llvm-svn: 245788
2015-08-23 03:40:49 +08:00
option(LIBCXX_INCLUDE_DOCS "Build the libc++ documentation." ${LLVM_INCLUDE_DOCS})
Reapply working parts of CMake cleanup. This patch adds the working parts of r243503. The difference with this patch is that it doesn't include the HandleLLVMOptions.cmake file. llvm-svn: 243698
2015-07-31 06:30:34 +08:00
set(LIBCXX_LIBDIR_SUFFIX "${LLVM_LIBDIR_SUFFIX}" CACHE STRING
"Define suffix of library directory name (32/64)")
option(LIBCXX_INSTALL_HEADERS "Install the libc++ headers." ON)
[libcxx] Remove installation rules on Darwin when it would overwrite the system installation. Summary: On Mac OS X overwriting `/usr/lib/libc++.dylib` can cause your computer to fail to boot. This patch tries to make it harder to do that accidentally. If `CMAKE_SYSTEM_NAME` is `Darwin` and `CMAKE_INSTALL_PREFIX` is `/usr` don't generate installation rules unless the user explicitly provides `LIBCXX_OVERRIDE_DARWIN_INSTALL=ON`. Note that `CMAKE_INSTALL_PREFIX` is always absolute so we don't need to worry about things like `/usr/../usr`. Reviewers: mclow.lists, beanz, jroelofs Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D12209 llvm-svn: 246070
2015-08-27 04:18:21 +08:00
option(LIBCXX_INSTALL_LIBRARY "Install the libc++ library." ON)
[CMake] Option to control whether shared/static library is installed Currently it's only possible to control whether shared or static library build of libc++, libc++abi and libunwind is enabled or disabled and whether to install everything we've built or not. However, it'd be useful to have more fine grained control, e.g. when static libraries are merged together into libc++.a we don't need to install libc++abi.a and libunwind.a. This change adds this option. Differential Revision: https://reviews.llvm.org/D49573 llvm-svn: 337867
2018-07-25 07:27:51 +08:00
cmake_dependent_option(LIBCXX_INSTALL_STATIC_LIBRARY
"Install the static libc++ library." ON
"LIBCXX_ENABLE_STATIC;LIBCXX_INSTALL_LIBRARY" OFF)
cmake_dependent_option(LIBCXX_INSTALL_SHARED_LIBRARY
"Install the shared libc++ library." ON
"LIBCXX_ENABLE_SHARED;LIBCXX_INSTALL_LIBRARY" OFF)
Enable installation of libc++experimental by default. When libc++experimental was originally created it was empty and therefore there was no reason to install it. Now that the library contains <experimental/memory_resource> and <experimental/filesystem> there is a good reason to install it. Specifically this patch enables the installation whenever LIBCXX_INSTALL_LIBRARY is true and LIBCPP_ENABLE_EXPERIMENTAL_LIBRARY is true. llvm-svn: 280773
2016-09-07 09:15:10 +08:00
cmake_dependent_option(LIBCXX_INSTALL_EXPERIMENTAL_LIBRARY
"Install libc++experimental.a" ON
"LIBCXX_ENABLE_EXPERIMENTAL_LIBRARY;LIBCXX_INSTALL_LIBRARY" OFF)
Implement <filesystem> This patch implements the <filesystem> header and uses that to provide <experimental/filesystem>. Unlike other standard headers, the symbols needed for <filesystem> have not yet been placed in libc++.so. Instead they live in the new libc++fs.a library. Users of filesystem are required to link this library. (Also note that libc++experimental no longer contains the definition of <experimental/filesystem>, which now requires linking libc++fs). The reason for keeping <filesystem> out of the dylib for now is that it's still somewhat experimental, and the possibility of requiring an ABI breaking change is very real. In the future the symbols will likely be moved into the dylib, or the dylib will be made to link libc++fs automagically). Note that moving the symbols out of libc++experimental may break user builds until they update to -lc++fs. This should be OK, because the experimental library provides no stability guarantees. However, I plan on looking into ways we can force libc++experimental to automagically link libc++fs. In order to use a single implementation and set of tests for <filesystem>, it has been placed in a special `__fs` namespace. This namespace is inline in C++17 onward, but not before that. As such implementation is available in C++11 onward, but no filesystem namespace is present "directly", and as such name conflicts shouldn't occur in C++11 or C++14. llvm-svn: 338093
2018-07-27 11:07:09 +08:00
[libc++] Remove Fuchsia-specific knowledge to pick the ABI version Summary: The ABI version used by libc++ is a configuration option just like any other configuration option. It is a knob that can be used by vendors to customize the libc++ that they ship. As such, we should not be hardcoding vendor-specific configuration choices in libc++. When building libc++ for Fuchsia, Fuchsia's build scripts should simply define the libc++ ABI version to 2 -- this will result in the _LIBCPP_ABI_VERSION macro being defined in the __config header that is generated when libc++ is built and installed, which is the correct way to customize libc++'s behavior for specific vendors. Reviewers: phosek, EricWF Subscribers: mgorny, christof, dexonsmith, cfe-commits, libcxx-commits Differential Revision: https://reviews.llvm.org/D52397 llvm-svn: 343079
2018-09-26 16:24:51 +08:00
set(LIBCXX_ABI_VERSION "1" CACHE STRING "ABI version of libc++. Can be either 1 or 2, where 2 is currently not stable. Defaults to 1.")
Make libc++'s versioning namespace customizable Summary: This patch makes the versioning namespace libc++ uses customizable by the user using `-DLIBCXX_ABI_NAMESPACE=__foo`. This allows users to build custom versions of libc++ which can be linked into binaries with other libc++ versions without causing symbol conflicts or ODR issues. Reviewers: mclow.lists, ldionne Reviewed By: ldionne Subscribers: kristina, smeenai, mgorny, phosek, libcxx-commits Differential Revision: https://reviews.llvm.org/D53879 llvm-svn: 345657
2018-10-31 05:44:53 +08:00
set(LIBCXX_ABI_NAMESPACE "" CACHE STRING "The inline ABI namespace used by libc++. It defaults to __n where `n` is the current ABI version.")
ABI versioning macros for libc++. C++ macros and CMake options that specify the default ABI version of the library, and can be overridden to pick up new ABI-changing features. llvm-svn: 250254
2015-10-14 07:48:28 +08:00
option(LIBCXX_ABI_UNSTABLE "Unstable ABI of libc++." OFF)
[libc++] Clarify names of ABI forcing macros Make it clear that these are intended only to force a specific ABI when the autodetection would give the wrong result by renaming the cmake options and adding separate forcing macros, as suggested by EricWF in the post-commit review of r314949 and further discussed on IRC. llvm-svn: 314965
2017-10-05 10:18:08 +08:00
option(LIBCXX_ABI_FORCE_ITANIUM "Ignore auto-detection and force use of the Itanium ABI.")
option(LIBCXX_ABI_FORCE_MICROSOFT "Ignore auto-detection and force use of the Microsoft ABI.")
Rework std::type_info definition to support systems without fully merged type info names. Previously std::type_info always expected type info string to be unique. But this isn't always the case. Like when -Bsymbolic is passed to the linker or due to llvm.org/PR37398. This patch adds the LIBCXX_HAS_MERGED_TYPEINFO_NAMES_DEFAULT CMake option which, when specified, overrides the default configuration for the library. The current defaults still assume unique names even though this isn't strictly correct for ELF binaries. We should consider changing the default in a follow up commit. llvm-svn: 361913
2019-05-29 10:21:37 +08:00
[libc++] Clarify how we pick the typeinfo comparison This commit makes it clear that the typeinfo comparison implementation is automatically selected by default, and that the CMake option only overrides the value. This has been a source of confusion and bugs ever since we've introduced complexity in that area, so I'm trying to simplify it while still allowing for some control on the implementation. Differential Revision: https://reviews.llvm.org/D91574
2020-11-17 07:13:43 +08:00
set(LIBCXX_TYPEINFO_COMPARISON_IMPLEMENTATION "default" CACHE STRING
"Override the implementation to use for comparing typeinfos. By default, this
is detected automatically by the library, but this option allows overriding
which implementation is used unconditionally.
See the documentation in <libcxx/include/typeinfo> for details on what each
value means.")
set(TYPEINFO_COMPARISON_VALUES "default;1;2;3")
if (NOT ("${LIBCXX_TYPEINFO_COMPARISON_IMPLEMENTATION}" IN_LIST TYPEINFO_COMPARISON_VALUES))
[libc++] Fix the LIBCXX_HAS_MERGED_TYPEINFO_NAMES_DEFAULT setting When the __config_site header is generated, but LIBCXX_HAS_MERGED_TYPEINFO_NAMES_DEFAULT wasn't specified, _LIBCPP_HAS_MERGED_TYPEINFO_NAMES_DEFAULT would be defined to 0, which was the NonUnique RTTI comparison implementation. The intent was to use the Unique RTTI comparison implementation in that case, which caused https://llvm.org/PR45549. Instead, use a proper "switch" to select the RTTI comparison implementation. Note that 0 can't be used as a value, because that is treated the same by CMake as a variable that is just not defined. Differential Revision: https://reviews.llvm.org/D80037
2020-05-16 03:58:19 +08:00
message(FATAL_ERROR "Value '${LIBCXX_TYPEINFO_COMPARISON_IMPLEMENTATION}' is not a valid value for
[libc++] Clarify how we pick the typeinfo comparison This commit makes it clear that the typeinfo comparison implementation is automatically selected by default, and that the CMake option only overrides the value. This has been a source of confusion and bugs ever since we've introduced complexity in that area, so I'm trying to simplify it while still allowing for some control on the implementation. Differential Revision: https://reviews.llvm.org/D91574
2020-11-17 07:13:43 +08:00
LIBCXX_TYPEINFO_COMPARISON_IMPLEMENTATION")
Rework std::type_info definition to support systems without fully merged type info names. Previously std::type_info always expected type info string to be unique. But this isn't always the case. Like when -Bsymbolic is passed to the linker or due to llvm.org/PR37398. This patch adds the LIBCXX_HAS_MERGED_TYPEINFO_NAMES_DEFAULT CMake option which, when specified, overrides the default configuration for the library. The current defaults still assume unique names even though this isn't strictly correct for ELF binaries. We should consider changing the default in a follow up commit. llvm-svn: 361913
2019-05-29 10:21:37 +08:00
endif()
[libcxx] By default, do not use internal_linkage to hide symbols from the ABI Summary: https://reviews.llvm.org/D49240 led to symbol size problems in Chromium, and we expect this may be the case in other projects built in debug mode too. Instead, unless users explicitly ask for internal_linkage, we use always_inline like we used to. In the future, when we have a solution that allows us to drop always_inline without falling back on internal_linkage, we can replace always_inline by that. Note that this commit introduces a change in contract for existing libc++ users: by default, libc++ used to guarantee that TUs built with different versions of libc++ could be linked together. With the introduction of the _LIBCPP_HIDE_FROM_ABI_PER_TU macro, the default behavior is that TUs built with different libc++ versions are not guaranteed to link. This is a change in contract but not a change in behavior, since the current implementation still allows linking TUs built with different libc++ versions together. Reviewers: EricWF, mclow.lists, dexonsmith, hans, rnk Subscribers: christof, cfe-commits Differential Revision: https://reviews.llvm.org/D50652 llvm-svn: 339874
2018-08-16 20:44:28 +08:00
option(LIBCXX_HIDE_FROM_ABI_PER_TU_BY_DEFAULT "Enable per TU ABI insulation by default. To be used by vendors." OFF)
[libc++] Move cache variable definition. NFC Move it to where the other ABI cache variables/options are defined. llvm-svn: 314950
2017-10-05 07:51:57 +08:00
set(LIBCXX_ABI_DEFINES "" CACHE STRING "A semicolon separated list of ABI macros to define in the site config header.")
libc++: add an option to build against compiler-rt This mirrors the option in libc++abi to build without libgcc. llvm-svn: 279606
2016-08-24 12:22:52 +08:00
option(LIBCXX_USE_COMPILER_RT "Use compiler-rt instead of libgcc" OFF)
[libc++][CMake] Clean up some of the libc++ re-exporting logic Summary: This change allows specifying the version of libc++abi's ABI to re-export when configuring CMake. It also clearly identifies which ABI version of libc++abi each export file contains. Finally, it removes hardcoded knowledge about the 10.9 SDK for MacOS, since that knowledge is not relevant anymore. Indeed, libc++ can't be built with the toolchain that came with the 10.9 SDK anyway because the version of Clang it includes is too old (for example if you want to build a working libc++.dylib, you need bugfixes to visibility attributes that are only in recent Clangs). Reviewers: dexonsmith, EricWF Subscribers: mgorny, christof, jkorous, arphaman, libcxx-commits Differential Revision: https://reviews.llvm.org/D59489 llvm-svn: 356587
2019-03-21 02:16:24 +08:00
set(LIBCXX_LIBCPPABI_VERSION "2" CACHE STRING "Version of libc++abi's ABI to re-export from libc++ when re-exporting is enabled.
Note that this is not related to the version of libc++'s ABI itself!")
Reapply working parts of CMake cleanup. This patch adds the working parts of r243503. The difference with this patch is that it doesn't include the HandleLLVMOptions.cmake file. llvm-svn: 243698
2015-07-31 06:30:34 +08:00
# ABI Library options ---------------------------------------------------------
[libc++] Simplify the configuration of the C++ ABI library This commit removes support for building against the system libc++abi, which was supported on Apple platforms. This is basically never what we want to do, since libc++ and libc++abi are coupled and building a trunk libc++ against an older libc++abi can lead to incompatibilities (and good luck debugging them!). It might have made some sense to support that when the monorepo did not exist, however I don't think this is anything but a footgun nowadays. Furthermore, based on the newly-made assumption that we're building against the monorepo libc++abi, we can simplify the search path logic for finding libc++abi. This area of our build system has a lot of technical debt accumulated, and it's surprisingly difficult to change. We've tried different things and failed several times in the past. I did test this change on our Docker image for the build bots and on Apple platforms, however it is possible that this breaks some unknown configuration, in which case it should be fine to revert this (so we can try again!).
2020-04-02 14:09:23 +08:00
set(LIBCXX_CXX_ABI "default" CACHE STRING "Specify C++ ABI library to use.")
Improve CMake and LIT support for Windows This patch contains multiple cleanups and fixes to better support building on Windows. * [Test] Fix handling of library runtime search paths by correctly adding them to the PATH variable when running the tests. * [Test] Don't explicitly force "--target=i686-pc-windows" when running the test suite. Clang++ seems to deduce the correct target. * [Test] Fix `.sh.cpp` tests on Windows by properly escaping flags used in shell commands. Specifically windows style paths which included spaces were causing these tests to fail. * [CMake] Add "vcruntime" to the list of supported C++ ABI libraries in CMake, and teach the test suite how to handle it. For now libc++ defaults to using "vcruntime" on Windows except when libc++abi is in tree; That is probably a bug and should be changed to always use vcruntime, at least for now. * [Misc] Move the "c++-build" include directory to the libc++ binary dir instead of the top level project dir and rename it "c++build". This is just misc cleanup. Libc++ shouldn't be creating internal build files and directories at the top-level projects root. * [Misc] Build type_info's destructor when building for MSVC. This is a temporary work around to prevent link errors until we have a proper type_info implementation. llvm-svn: 292157
2017-01-17 04:47:35 +08:00
set(CXXABIS none default libcxxabi libcxxrt libstdc++ libsupc++ vcruntime)
Reapply working parts of CMake cleanup. This patch adds the working parts of r243503. The difference with this patch is that it doesn't include the HandleLLVMOptions.cmake file. llvm-svn: 243698
2015-07-31 06:30:34 +08:00
set_property(CACHE LIBCXX_CXX_ABI PROPERTY STRINGS ;${CXXABIS})
Only disable linker script when LIBCXX_CXX_ABI_LIBNAME is none llvm-svn: 251063
2015-10-23 04:54:27 +08:00
# Setup the default options if LIBCXX_CXX_ABI is not specified.
Recommit r290839 - Fix configuring and building libc++ w/o an ABI library. 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
2017-01-03 09:18:48 +08:00
if (LIBCXX_CXX_ABI STREQUAL "default")
[libc++] Default to vcruntime when targeting MSVC Summary: libc++abi is never the right option for LIBCXX_TARGETING_MSVC, since it targets the Itanium ABI, whereas MSVC uses the Microsoft ABI. Make the default ABI be vcruntime when targeting MSVC even if libc++abi is present in the tree. Differential Revision: https://reviews.llvm.org/D32320 llvm-svn: 300921
2017-04-21 07:33:49 +08:00
if (LIBCXX_TARGETING_MSVC)
# FIXME: Figure out how to configure the ABI library on Windows.
set(LIBCXX_CXX_ABI_LIBNAME "vcruntime")
Add default C++ ABI libname and include paths for FreeBSD Summary: As noted in a discussion about testing the LLVM 6.0.0 release candidates (with libc++) for FreeBSD, many tests turned out to fail with "exception_ptr not yet implemented". This was because libc++ did not choose the correct C++ ABI library, and therefore it fell back to the `exception_fallback.ipp` header. Since FreeBSD 10.x, we have been using libcxxrt as our C++ ABI library, and its headers have always been installed in /usr/include/c++/v1, together with the (system) libc++ headers. (Older versions of FreeBSD used GNU libsupc++ by default, but these are now unsupported.) Therefore, if we are building libc++ for FreeBSD, set: * `LIBCXX_CXX_ABI_LIBNAME` to "libcxxrt" * `LIBCXX_CXX_ABI_INCLUDE_PATHS` to "/usr/include/c++/v1" by default. Reviewers: emaste, EricWF, mclow.lists Reviewed By: EricWF Subscribers: mgorny, cfe-commits, krytarowski Differential Revision: https://reviews.llvm.org/D43166 llvm-svn: 324855
2018-02-12 06:31:05 +08:00
elseif (${CMAKE_SYSTEM_NAME} MATCHES "FreeBSD")
set(LIBCXX_CXX_ABI_LIBNAME "libcxxrt")
[libc++] Simplify the configuration of the C++ ABI library This commit removes support for building against the system libc++abi, which was supported on Apple platforms. This is basically never what we want to do, since libc++ and libc++abi are coupled and building a trunk libc++ against an older libc++abi can lead to incompatibilities (and good luck debugging them!). It might have made some sense to support that when the monorepo did not exist, however I don't think this is anything but a footgun nowadays. Furthermore, based on the newly-made assumption that we're building against the monorepo libc++abi, we can simplify the search path logic for finding libc++abi. This area of our build system has a lot of technical debt accumulated, and it's surprisingly difficult to change. We've tried different things and failed several times in the past. I did test this change on our Docker image for the build bots and on Apple platforms, however it is possible that this breaks some unknown configuration, in which case it should be fine to revert this (so we can try again!).
2020-04-02 14:09:23 +08:00
elseif (NOT LIBCXX_STANDALONE_BUILD OR HAVE_LIBCXXABI)
set(LIBCXX_CXX_ABI_LIBNAME "libcxxabi")
CMakeLists.txt cleanups: synchronize version with rest of LLVM, consistent spacing. Differential revision: https://reviews.llvm.org/D23091 llvm-svn: 278032
2016-08-09 02:01:50 +08:00
else()
[libc++] Default to vcruntime when targeting MSVC Summary: libc++abi is never the right option for LIBCXX_TARGETING_MSVC, since it targets the Itanium ABI, whereas MSVC uses the Microsoft ABI. Make the default ABI be vcruntime when targeting MSVC even if libc++abi is present in the tree. Differential Revision: https://reviews.llvm.org/D32320 llvm-svn: 300921
2017-04-21 07:33:49 +08:00
set(LIBCXX_CXX_ABI_LIBNAME "default")
CMakeLists.txt cleanups: synchronize version with rest of LLVM, consistent spacing. Differential revision: https://reviews.llvm.org/D23091 llvm-svn: 278032
2016-08-09 02:01:50 +08:00
endif()
else()
Only disable linker script when LIBCXX_CXX_ABI_LIBNAME is none llvm-svn: 251063
2015-10-23 04:54:27 +08:00
set(LIBCXX_CXX_ABI_LIBNAME "${LIBCXX_CXX_ABI}")
CMakeLists.txt cleanups: synchronize version with rest of LLVM, consistent spacing. Differential revision: https://reviews.llvm.org/D23091 llvm-svn: 278032
2016-08-09 02:01:50 +08:00
endif()
Only disable linker script when LIBCXX_CXX_ABI_LIBNAME is none llvm-svn: 251063
2015-10-23 04:54:27 +08:00
[libc++][NFC] Promote CMake comment to an actual option description llvm-svn: 356386
2019-03-19 02:18:01 +08:00
option(LIBCXX_ENABLE_STATIC_ABI_LIBRARY
"Use a static copy of the ABI library when linking libc++.
This option cannot be used with LIBCXX_ENABLE_ABI_LINKER_SCRIPT." OFF)
Reapply working parts of CMake cleanup. This patch adds the working parts of r243503. The difference with this patch is that it doesn't include the HandleLLVMOptions.cmake file. llvm-svn: 243698
2015-07-31 06:30:34 +08:00
Reland "[CMake] Support statically linking dependencies only to shared or static library" This is a reland of commit r337668. llvm-svn: 337814
2018-07-24 15:06:17 +08:00
cmake_dependent_option(LIBCXX_STATICALLY_LINK_ABI_IN_STATIC_LIBRARY
"Statically link the ABI library to static library" ON
"LIBCXX_ENABLE_STATIC_ABI_LIBRARY;LIBCXX_ENABLE_STATIC" OFF)
cmake_dependent_option(LIBCXX_STATICALLY_LINK_ABI_IN_SHARED_LIBRARY
"Statically link the ABI library to shared library" ON
[CMake] Fix the LIBCXX_STATICALLY_LINK_ABI_IN_SHARED_LIBRARY option This option should be available if LIBCXX_ENABLE_SHARED is enabled, not LIBCXX_ENABLE_STATIC. This fixes a typo from SVN r337814. Differential Revision: https://reviews.llvm.org/D50691 llvm-svn: 339697
2018-08-15 01:33:10 +08:00
"LIBCXX_ENABLE_STATIC_ABI_LIBRARY;LIBCXX_ENABLE_SHARED" OFF)
Reland "[CMake] Support statically linking dependencies only to shared or static library" This is a reland of commit r337668. llvm-svn: 337814
2018-07-24 15:06:17 +08:00
[libcxx] Make it drastically simpler to link libc++. Summary: Currently on most platforms you have to manually link the c++ abi library used with libc++ whenever you use libc++. So your typical libc++ command like invocation might look like: ``` clang++ -stdlib=libc++ foo.cpp -lc++abi ``` Having to manually link `libc++abi.so` makes it harder for libc++ to be used generically. This patch fixes that by generating a linker script for `libc++.so` that correctly links the ABI library. On linux the linker script for libc++abi would look like: ``` # libc++.so INPUT(libc++.so.1 -lc++abi) ``` With the linker script you can now use libc++ using only `-stdlib=libc++`. This is the technique that is used on FreeBSD in ordered to link cxxrt and I think it's the best approach to make our users lives simpler. The CMake option used to enable this is `LIBCXX_ENABLE_ABI_LINKER_SCRIPT`. In future I would like to enable this by default on all platforms except for Darwin. Reviewers: mclow.lists, danalbert, rsmith, jroelofs, EricWF Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D12508 llvm-svn: 250319
2015-10-15 03:54:03 +08:00
# Generate and install a linker script inplace of libc++.so. The linker script
[libcxx] Make libc++.so a linker script by default on most platforms. Summary: This patch turns on `LIBCXX_ENABLE_ABI_LINKER_SCRIPT` by default whenever `LLVM_HAVE_LINK_VERSION_SCRIPT` is ON. This turns out to be whenever: 1. WIN32 is not defined. 2 UNIX is defined. 3. APPLE is not defined. While `LLVM_HAVE_LINK_VERSION_SCRIPT` is meant to reflect exactly what we are asking I think it's close enough. After committing this patch Linux users will no longer have to use "-lc++abi" explicitly! Reviewers: mclow.lists, danalbert, compnerd, jroelofs Subscribers: emaste, rengolin, cbergstrom, cfe-commits Differential Revision: http://reviews.llvm.org/D13739 llvm-svn: 250469
2015-10-16 06:41:51 +08:00
# will link libc++ to the correct ABI library. This option is on by default
[libc++] Fix capitalization in comment Fix a stray capital letter in the middle of a sentence. No functional change. llvm-svn: 298763
2017-03-25 11:22:35 +08:00
# on UNIX platforms other than Apple unless 'LIBCXX_ENABLE_STATIC_ABI_LIBRARY'
Disable linker scripts when the ABI library is not specified or is none. llvm-svn: 251062
2015-10-23 04:50:07 +08:00
# is on. This option is also disabled when the ABI library is not specified
# or is specified to be "none".
[libcxx] Make libc++.so a linker script by default on most platforms. Summary: This patch turns on `LIBCXX_ENABLE_ABI_LINKER_SCRIPT` by default whenever `LLVM_HAVE_LINK_VERSION_SCRIPT` is ON. This turns out to be whenever: 1. WIN32 is not defined. 2 UNIX is defined. 3. APPLE is not defined. While `LLVM_HAVE_LINK_VERSION_SCRIPT` is meant to reflect exactly what we are asking I think it's close enough. After committing this patch Linux users will no longer have to use "-lc++abi" explicitly! Reviewers: mclow.lists, danalbert, compnerd, jroelofs Subscribers: emaste, rengolin, cbergstrom, cfe-commits Differential Revision: http://reviews.llvm.org/D13739 llvm-svn: 250469
2015-10-16 06:41:51 +08:00
set(ENABLE_LINKER_SCRIPT_DEFAULT_VALUE OFF)
[CMake] Don't generate linker script only when shared library isn't statically linked Since r337668, we support statically linking dependencies only to shared or static library. However, that change hasn't updated the check whether to generate a linker script. We shouldn't generate linker script only in the case when we aren't statically linked ABI into the shared library. Differential Revision: https://reviews.llvm.org/D49834 llvm-svn: 338006
2018-07-26 13:10:24 +08:00
if (LLVM_HAVE_LINK_VERSION_SCRIPT AND NOT LIBCXX_STATICALLY_LINK_ABI_IN_SHARED_LIBRARY
Only disable linker script when LIBCXX_CXX_ABI_LIBNAME is none llvm-svn: 251063
2015-10-23 04:54:27 +08:00
AND NOT LIBCXX_CXX_ABI_LIBNAME STREQUAL "none"
Recommit r290839 - Fix configuring and building libc++ w/o an ABI library. 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
2017-01-03 09:18:48 +08:00
AND NOT LIBCXX_CXX_ABI_LIBNAME STREQUAL "default"
Revert "Temporarily revert "build: use `find_package(Python3)` if available"" This reverts commit 35edd704e0fda09e8e634515c0b451d4a8b6b914. Revert the revert and extend the patch further to account for the use of the `PYTHONINTERP_FOUND`.
2020-04-29 09:37:28 +08:00
AND Python3_EXECUTABLE
Disable LIBCXX_ENABLE_ABI_LINKER_SCRIPT for static library builds. This option is geared towards shared library builds and causes static library builds to fail if not explicitly disabled. This patch fixes PR27706: https://llvm.org/bugs/show_bug.cgi?id=27706 Thanks rgoodfel@isi.edu for the catch. llvm-svn: 269585
2016-05-15 07:58:11 +08:00
AND LIBCXX_ENABLE_SHARED)
[libcxx] Make libc++.so a linker script by default on most platforms. Summary: This patch turns on `LIBCXX_ENABLE_ABI_LINKER_SCRIPT` by default whenever `LLVM_HAVE_LINK_VERSION_SCRIPT` is ON. This turns out to be whenever: 1. WIN32 is not defined. 2 UNIX is defined. 3. APPLE is not defined. While `LLVM_HAVE_LINK_VERSION_SCRIPT` is meant to reflect exactly what we are asking I think it's close enough. After committing this patch Linux users will no longer have to use "-lc++abi" explicitly! Reviewers: mclow.lists, danalbert, compnerd, jroelofs Subscribers: emaste, rengolin, cbergstrom, cfe-commits Differential Revision: http://reviews.llvm.org/D13739 llvm-svn: 250469
2015-10-16 06:41:51 +08:00
set(ENABLE_LINKER_SCRIPT_DEFAULT_VALUE ON)
endif()
[libcxx] Make it drastically simpler to link libc++. Summary: Currently on most platforms you have to manually link the c++ abi library used with libc++ whenever you use libc++. So your typical libc++ command like invocation might look like: ``` clang++ -stdlib=libc++ foo.cpp -lc++abi ``` Having to manually link `libc++abi.so` makes it harder for libc++ to be used generically. This patch fixes that by generating a linker script for `libc++.so` that correctly links the ABI library. On linux the linker script for libc++abi would look like: ``` # libc++.so INPUT(libc++.so.1 -lc++abi) ``` With the linker script you can now use libc++ using only `-stdlib=libc++`. This is the technique that is used on FreeBSD in ordered to link cxxrt and I think it's the best approach to make our users lives simpler. The CMake option used to enable this is `LIBCXX_ENABLE_ABI_LINKER_SCRIPT`. In future I would like to enable this by default on all platforms except for Darwin. Reviewers: mclow.lists, danalbert, rsmith, jroelofs, EricWF Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D12508 llvm-svn: 250319
2015-10-15 03:54:03 +08:00
option(LIBCXX_ENABLE_ABI_LINKER_SCRIPT
[libcxx] Make libc++.so a linker script by default on most platforms. Summary: This patch turns on `LIBCXX_ENABLE_ABI_LINKER_SCRIPT` by default whenever `LLVM_HAVE_LINK_VERSION_SCRIPT` is ON. This turns out to be whenever: 1. WIN32 is not defined. 2 UNIX is defined. 3. APPLE is not defined. While `LLVM_HAVE_LINK_VERSION_SCRIPT` is meant to reflect exactly what we are asking I think it's close enough. After committing this patch Linux users will no longer have to use "-lc++abi" explicitly! Reviewers: mclow.lists, danalbert, compnerd, jroelofs Subscribers: emaste, rengolin, cbergstrom, cfe-commits Differential Revision: http://reviews.llvm.org/D13739 llvm-svn: 250469
2015-10-16 06:41:51 +08:00
"Use and install a linker script for the given ABI library"
Re-enable linker scripts after fixing bad CMake llvm-svn: 250472
2015-10-16 07:04:54 +08:00
${ENABLE_LINKER_SCRIPT_DEFAULT_VALUE})
[libcxx] Make it drastically simpler to link libc++. Summary: Currently on most platforms you have to manually link the c++ abi library used with libc++ whenever you use libc++. So your typical libc++ command like invocation might look like: ``` clang++ -stdlib=libc++ foo.cpp -lc++abi ``` Having to manually link `libc++abi.so` makes it harder for libc++ to be used generically. This patch fixes that by generating a linker script for `libc++.so` that correctly links the ABI library. On linux the linker script for libc++abi would look like: ``` # libc++.so INPUT(libc++.so.1 -lc++abi) ``` With the linker script you can now use libc++ using only `-stdlib=libc++`. This is the technique that is used on FreeBSD in ordered to link cxxrt and I think it's the best approach to make our users lives simpler. The CMake option used to enable this is `LIBCXX_ENABLE_ABI_LINKER_SCRIPT`. In future I would like to enable this by default on all platforms except for Darwin. Reviewers: mclow.lists, danalbert, rsmith, jroelofs, EricWF Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D12508 llvm-svn: 250319
2015-10-15 03:54:03 +08:00
[libc++] Add option to disable new/delete overloads when libc++abi provides them. Summary: Currently both libc++ and libc++abi provide definitions for operator new/delete. However I believe this is incorrect and that one or the other should offer them. This patch adds the CMake option `-DLIBCXX_ENABLE_NEW_DELETE_DEFINITIONS` which defaults no `ON` unless `-DLIBCXXABI_ENABLE_NEW_DELETE_DEFINITIONS=ON` is specified. Reviewers: mclow.lists, mehdi_amini, dexonsmith, danalbert, smeenai, mgorny, rmaprath Reviewed By: mehdi_amini Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D30516 llvm-svn: 296802
2017-03-03 03:35:33 +08:00
option(LIBCXX_ENABLE_NEW_DELETE_DEFINITIONS
[libc++] Define new/delete in libc++abi only by default Previously, we would define new/delete in both libc++ and libc++abi. Not only does this cause code bloat, but also it's technically an ODR violation since we don't know which operator will be selected. Furthermore, since those are weak definitions, we should strive to have as few of them as possible (to improve load times). My preferred choice would have been to put the operators in libc++ only by default, however that would create a circular dependency between libc++ and libc++abi, which GNU linkers don't handle. Folks who want to ship new/delete in libc++ instead of libc++abi are free to do so by turning on LIBCXX_ENABLE_NEW_DELETE_DEFINITIONS at CMake configure time. On Apple platforms, this shouldn't be an ABI break because we re-export the new/delete symbols from libc++abi. This change actually makes libc++ behave closer to the system libc++ shipped on Apple platforms. On other platforms, this is an ABI break for people linking against libc++ but not libc++abi. However, vendors have been consulted in D68269 and no objection was raised. Furthermore, the definitions can be controlled to appear in libc++ instead with the CMake option. Differential Revision: https://reviews.llvm.org/D68269
2019-10-01 21:34:58 +08:00
"Build libc++ with definitions for operator new/delete. These are normally
defined in libc++abi, but this option can be used to define them in libc++
instead. If you define them in libc++, make sure they are NOT defined in
libc++abi. Doing otherwise is an ODR violation." OFF)
Reapply working parts of CMake cleanup. This patch adds the working parts of r243503. The difference with this patch is that it doesn't include the HandleLLVMOptions.cmake file. llvm-svn: 243698
2015-07-31 06:30:34 +08:00
# Build libc++abi with libunwind. We need this option to determine whether to
# link with libunwind or libgcc_s while running the test cases.
option(LIBCXXABI_USE_LLVM_UNWINDER "Build and use the LLVM unwinder." OFF)
# Target options --------------------------------------------------------------
option(LIBCXX_BUILD_32_BITS "Build 32 bit libc++." ${LLVM_BUILD_32_BITS})
[CMake] Support CMake variables for setting target, sysroot and toolchain CMake has a standard way of setting target triple, sysroot and external toolchain through CMAKE_<LANG>_COMPILER_TARGET, CMAKE_SYSROOT and CMAKE_<LANG>_COMPILER_EXTERNAL_TOOLCHAIN. These are turned into corresponding --target=, --sysroot= and --gcc-toolchain= variables add included appended to CMAKE_<LANG>_FLAGS. libunwind, libc++abi, libc++ provides their own mechanism through <PROJECT>_TARGET_TRIPLE, <PROJECT>_SYSROOT and <PROJECT>_GCC_TOOLCHAIN variables. These are also passed to lit via lit.site.cfg, and lit config uses these to set the corresponding compiler flags when building tessts. This means that there are two different ways of setting target, sysroot and toolchain, but only one is properly supported in lit. This change extends CMake build for libunwind, libc++abi and libc++ to also support the CMake variables in addition to project specific ones in lit. Differential Revision: https://reviews.llvm.org/D57670 llvm-svn: 353084
2019-02-05 04:02:26 +08:00
set(LIBCXX_TARGET_TRIPLE "" CACHE STRING "Use alternate target triple.")
Reapply working parts of CMake cleanup. This patch adds the working parts of r243503. The difference with this patch is that it doesn't include the HandleLLVMOptions.cmake file. llvm-svn: 243698
2015-07-31 06:30:34 +08:00
set(LIBCXX_SYSROOT "" CACHE STRING "Use alternate sysroot.")
set(LIBCXX_GCC_TOOLCHAIN "" CACHE STRING "Use alternate GCC toolchain.")
# Feature options -------------------------------------------------------------
option(LIBCXX_ENABLE_EXCEPTIONS "Use exceptions." ON)
option(LIBCXX_ENABLE_RTTI "Use run time type information." ON)
Add option to disable access to the global filesystem namespace. Systems like FreeBSD's Capsicum and Nuxi CloudABI apply the concept of capability-based security on the way processes can interact with the filesystem API. It is no longer possible to interact with the VFS through calls like open(), unlink(), rename(), etc. Instead, processes are only allowed to interact with files and directories to which they have been granted access. The *at() functions can be used for this purpose. This change adds a new config switch called _LIBCPP_HAS_NO_GLOBAL_FILESYSTEM_NAMESPACE. If set, all functionality that requires the global filesystem namespace will be disabled. More concretely: - fstream's open() function will be removed. - cstdio will no longer pull in fopen(), rename(), etc. - The test suite's get_temp_file_name() will be removed. This will cause all tests that use the global filesystem namespace to break, but will at least make all the other tests run (as get_temp_file_name will not build anyway). It is important to mention that this change will make fstream rather useless on those systems for now. Still, I'd rather not have fstream disabled entirely, as it is of course possible to come up with an extension for fstream that would allow access to local filesystem namespaces (e.g., by adding an openat() member function). Differential revision: http://reviews.llvm.org/D8194 Reviewed by: jroelofs (thanks!) llvm-svn: 232049
2015-03-12 23:44:39 +08:00
option(LIBCXX_ENABLE_GLOBAL_FILESYSTEM_NAMESPACE "Build libc++ with support for the global filesystem namespace." ON)
Make the presence of stdin and stdout optional. The idea behind Nuxi CloudABI is that it is targeted at (but not limited to) running networked services in a sandboxed environment. The model behind stdin, stdout and stderr is strongly focused on interactive tools in a command shell. CloudABI does not support the notion of stdin and stdout, as 'standard input/output' does not apply to services. The concept of stderr does makes sense though, as services do need some mechanism to log error messages in a uniform way. This patch extends libc++ in such a way that std::cin and std::cout and the associated <cstdio>/<cwchar> functions can be disabled through the flags _LIBCPP_HAS_NO_STDIN and _LIBCPP_HAS_NO_STDOUT, respectively. At the same time it attempts to clean up src/iostream.cpp a bit. Instead of using a single array of mbstate_t objects and hardcoding the array indices, it creates separate objects that declared next to the iostream objects and their buffers. The code is also restructured by interleaving the construction and setup of c* and wc* objects. That way it is more obvious that this is done identically. The c* and wc* objects already have separate unit tests. Make use of this fact by adding XFAILs in case libcpp-has-no-std* is set. That way the tests work in both directions. If stdin or stdout is disabled, these tests will therefore test for the absence of c* and wc*. Differential Revision: http://reviews.llvm.org/D8340 llvm-svn: 233275
2015-03-26 22:35:46 +08:00
option(LIBCXX_ENABLE_STDIN "Build libc++ with support for stdin/std::cin." ON)
option(LIBCXX_ENABLE_STDOUT "Build libc++ with support for stdout/std::cout." ON)
Add support for building and testing libc++ without threads to CMake. Currently hacks must be used in to configure and build libc++ without threads when using CMake. This patch adds CMake options to enable/disable building with threads and a monotonic clock. This patch also propagates the configuration information to lit so the tests are properly configured as well. llvm-svn: 223591
2014-12-07 05:02:58 +08:00
option(LIBCXX_ENABLE_THREADS "Build libc++ with support for threads." ON)
Make support for thread-unsafe C functions optional. One of the aspects of CloudABI is that it aims to help you write code that is thread-safe out of the box. This is very important if you want to write libraries that are easy to reuse. For CloudABI we decided to not provide the thread-unsafe functions. So far this is working out pretty well, as thread-unsafety issues are detected really early on. The following patch adds a knob to libc++, _LIBCPP_HAS_NO_THREAD_UNSAFE_C_FUNCTIONS, that can be set to disable thread-unsafe functions that can easily be avoided in practice. The following functions are not thread-safe: - <clocale>: locale handles should be preferred over setlocale(). - <cstdlib>: mbrlen(), mbrtowc() and wcrtomb() should be preferred over their non-restartable counterparts. - <ctime>: asctime(), ctime(), gmtime() and localtime() are not thread-safe. The first two are also deprecated by POSIX. Differential Revision: http://reviews.llvm.org/D8703 Reviewed by: marshall llvm-svn: 240527
2015-06-24 16:44:38 +08:00
option(LIBCXX_ENABLE_THREAD_UNSAFE_C_FUNCTIONS "Build libc++ with support for thread-unsafe C functions" ON)
Add support for building and testing libc++ without threads to CMake. Currently hacks must be used in to configure and build libc++ without threads when using CMake. This patch adds CMake options to enable/disable building with threads and a monotonic clock. This patch also propagates the configuration information to lit so the tests are properly configured as well. llvm-svn: 223591
2014-12-07 05:02:58 +08:00
option(LIBCXX_ENABLE_MONOTONIC_CLOCK
"Build libc++ with support for a monotonic clock.
Misc drive-by cleanups. NFC http://reviews.llvm.org/D12294 llvm-svn: 245876
2015-08-25 05:20:07 +08:00
This option may only be set to OFF when LIBCXX_ENABLE_THREADS=OFF." ON)
Add initial support for the MUSL C library. Summary: This patch adds the LIBCXX_LIBC_IS_MUSL cmake option to allow the building of libcxx with the Musl C library. The option is necessary as Musl does not provide any predefined macro in order to test for its presence, like GLIBC. Most of the changes specify the correct path to choose through the various #if/#else constructs in the locale code. Depends on D13407. Reviewers: mclow.lists, jroelofs, EricWF Subscribers: jfb, tberghammer, danalbert, srhines, cfe-commits Differential Revision: http://reviews.llvm.org/D13673 llvm-svn: 252457
2015-11-09 18:21:04 +08:00
option(LIBCXX_HAS_MUSL_LIBC "Build libc++ with support for the Musl C library" OFF)
[libcxx] Allow explicit pthread opt-in The existing pthread detection code in __config is pretty good for common operating systems. It doesn't allow cmake-time choices to be made for uncommon operating systems though. This change adds the LIBCXX_HAS_PTHREAD_API cmake flag, which turns into the _LIBCPP_HAS_THREAD_API_PTHREAD preprocessor define. This is a name change from the old _LIBCPP_THREAD_API_PTHREAD. The lit tests want __config_site.in variables to have a _LIBCPP_HAS prefix. http://reviews.llvm.org/D20573 llvm-svn: 270735
2016-05-26 01:40:09 +08:00
option(LIBCXX_HAS_PTHREAD_API "Ignore auto-detection and force use of pthread API" OFF)
[cmake] Add a config option LIBCXX_HAS_WIN32_THREAD_API for enforcing win32 threads This allows keeping libcxx using win32 threads even if a version of pthread.h is installed. This matches the existing cmake option LIBCXX_HAS_PTHREAD_API. Also add missing documentation about the internal define _LIBCPP_HAS_THREAD_API_WIN32. Differential Revision: https://reviews.llvm.org/D41764 llvm-svn: 321896
2018-01-06 04:48:29 +08:00
option(LIBCXX_HAS_WIN32_THREAD_API "Ignore auto-detection and force use of win32 thread API" OFF)
[libcxx] Introduce an externally-threaded libc++ variant. This patch further decouples libc++ from pthread, allowing libc++ to be built against other threading systems. There are two main use cases: - Building libc++ against a thread library other than pthreads. - Building libc++ with an "external" thread API, allowing a separate library to provide the implementation of that API. The two use cases are quite similar, the second one being sligtly more de-coupled than the first. The cmake option LIBCXX_HAS_EXTERNAL_THREAD_API enables both kinds of builds. One needs to place an <__external_threading> header file containing an implementation of the "libc++ thread API" declared in the <__threading_support> header. For the second use case, the implementation of the libc++ thread API can delegate to a custom "external" thread API where the implementation of this external API is provided in a seperate library. This mechanism allows toolchain vendors to distribute a build of libc++ with a custom thread-porting-layer API (which is the "external" API above), platform vendors (recipients of the toolchain/libc++) are then required to provide their implementation of this API to be linked with (end-user) C++ programs. Note that the second use case still requires establishing the basic types that get passed between the external thread library and the libc++ library (e.g. __libcpp_mutex_t). These cannot be opaque pointer types (libc++ sources won't compile otherwise). It should also be noted that the second use case can have a slight performance penalty; as all the thread constructs need to cross a library boundary through an additional function call. When the header <__external_threading> is omitted, libc++ is built with the "libc++ thread API" (declared in <__threading_support>) as the "external" thread API (basic types are pthread based). An implementation (pthread based) of this API is provided in test/support/external_threads.cpp, which is built into a separate DSO and linked in when running the libc++ test suite. A test run therefore demonstrates the second use case (less the intermediate custom API). Differential revision: https://reviews.llvm.org/D21968 Reviewers: bcraig, compnerd, EricWF, mclow.lists llvm-svn: 281179
2016-09-12 05:46:40 +08:00
option(LIBCXX_HAS_EXTERNAL_THREAD_API
"Build libc++ with an externalized threading API.
This option may only be set to ON when LIBCXX_ENABLE_THREADS=ON." OFF)
[libc++] Cleanup and document <__threading_support> Summary: This patch attempts to clean up the macro configuration mess in `<__threading_support>`, specifically the mess involving external threading variants. Additionally this patch adds design documentation for `<__threading_support>` and the configuration macros it uses. The primary change in this patch is separating the idea of an "external API" provided by `<__external_threading>` and the idea of having an external threading library. Now `_LIBCPP_HAS_THREAD_API_EXTERNAL` means that libc++ should use `<__external_threading>` and that the header is expected to exist. Additionally the new macro `_LIBCPP_HAS_THREAD_LIBRARY_EXTERNAL` is now used to configure for using an "external library" with the default threading API. Reviewers: compnerd, rmaprath Subscribers: smeenai, cfe-commits, mgorny Differential Revision: https://reviews.llvm.org/D28316 llvm-svn: 291275
2017-01-07 04:05:40 +08:00
option(LIBCXX_BUILD_EXTERNAL_THREAD_LIBRARY
"Build libc++ with an externalized threading library.
This option may only be set to ON when LIBCXX_ENABLE_THREADS=ON" OFF)
Reapply working parts of CMake cleanup. This patch adds the working parts of r243503. The difference with this patch is that it doesn't include the HandleLLVMOptions.cmake file. llvm-svn: 243698
2015-07-31 06:30:34 +08:00
# Misc options ----------------------------------------------------------------
Turn off -pedantic by default when building due to #include_next. :-( llvm-svn: 249939
2015-10-10 11:34:52 +08:00
# FIXME: Turn -pedantic back ON. It is currently off because it warns
# about #include_next which is used everywhere.
option(LIBCXX_ENABLE_PEDANTIC "Compile with pedantic enabled." OFF)
Reapply working parts of CMake cleanup. This patch adds the working parts of r243503. The difference with this patch is that it doesn't include the HandleLLVMOptions.cmake file. llvm-svn: 243698
2015-07-31 06:30:34 +08:00
option(LIBCXX_ENABLE_WERROR "Fail and stop if a warning is triggered." OFF)
Add option to disable __deallocate #warning From r229162: Visual Studio's SAL extension uses a macro named __deallocate. This macro is used pervasively Using -Werror when building for Windows can force the use of -Wno-#warnings specifically because of this __deallocate #warning. Instead of forcing builds to disable all #warnings, this option allows libc++ to be built without this particular warning, while leaving other #warnings enabled. Patch by Dave Lee! llvm-svn: 275172
2016-07-12 22:39:13 +08:00
option(LIBCXX_DISABLE_MACRO_CONFLICT_WARNINGS "Disable #warnings about conflicting macros." OFF)
Reapply working parts of CMake cleanup. This patch adds the working parts of r243503. The difference with this patch is that it doesn't include the HandleLLVMOptions.cmake file. llvm-svn: 243698
2015-07-31 06:30:34 +08:00
[libcxx] Add code coverage configuration to CMake and LIT. Summary: This patch adds configuration to CMake and LIT for running the libc++ test-suite to generate code coverage. To use code coverage use following instructions. * Find the clang resource dir using `$CXX -print-search-dirs`. Let <library-dir> be the first library search directory. * `cmake <regular-options> -DLIBCXX_GENERATE_COVERAGE=ON -DLIBCXX_COVERAGE_LIBRARY=<library-dir>/lib/<platform>/libclang_rt.profile.a <source>` * `make cxx` * `make check-libcxx` * `make generate-libcxx-coverage` The reason I want this patch upstreamed is so I can setup a bot that generates code coverage and posts in online for every revision. Reviewers: mclow.lists, jroelofs, danalbert Reviewed By: danalbert Differential Revision: http://reviews.llvm.org/D8716 llvm-svn: 233669
2015-03-31 12:15:45 +08:00
option(LIBCXX_GENERATE_COVERAGE "Enable generating code coverage." OFF)
set(LIBCXX_COVERAGE_LIBRARY "" CACHE STRING
Reapply working parts of CMake cleanup. This patch adds the working parts of r243503. The difference with this patch is that it doesn't include the HandleLLVMOptions.cmake file. llvm-svn: 243698
2015-07-31 06:30:34 +08:00
"The Profile-rt library used to build with code coverage")
Add CMake option LIBCXX_CONFIGURE_IDE to allow for other IDE's. CLion needs similar configuration changes as MSVC_IDE and XCODE. llvm-svn: 255851
2015-12-17 07:41:05 +08:00
set(LIBCXX_CONFIGURE_IDE_DEFAULT OFF)
if (XCODE OR MSVC_IDE)
set(LIBCXX_CONFIGURE_IDE_DEFAULT ON)
endif()
option(LIBCXX_CONFIGURE_IDE "Configure libcxx for use within an IDE"
${LIBCXX_CONFIGURE_IDE_DEFAULT})
[libcxx] Support building hermetic static library This is useful when static libc++ library is being linked into shared libraries that may be used in combination with libraries. We want to avoid we exporting libc++ symbols in those cases where this option is useful. This is provided as a CMake option and can be enabled by libc++ vendors as needed. Differential Revision: https://reviews.llvm.org/D55404 llvm-svn: 350489
2019-01-06 14:14:31 +08:00
option(LIBCXX_HERMETIC_STATIC_LIBRARY
"Do not export any symbols from the static library." OFF)
Reapply working parts of CMake cleanup. This patch adds the working parts of r243503. The difference with this patch is that it doesn't include the HandleLLVMOptions.cmake file. llvm-svn: 243698
2015-07-31 06:30:34 +08:00
#===============================================================================
# Check option configurations
#===============================================================================
# Ensure LIBCXX_ENABLE_MONOTONIC_CLOCK is set to ON only when
# LIBCXX_ENABLE_THREADS is on.
if(LIBCXX_ENABLE_THREADS AND NOT LIBCXX_ENABLE_MONOTONIC_CLOCK)
message(FATAL_ERROR "LIBCXX_ENABLE_MONOTONIC_CLOCK can only be set to OFF"
" when LIBCXX_ENABLE_THREADS is also set to OFF.")
Recommit r243503 "[libcxx] Cleanup CMake configuration and integrate with LLVM" This change was reverted in r243550 because it broke clang-format builds (see PR24306). This patch recommits a fixed version of the original. llvm-svn: 243574
2015-07-30 05:07:28 +08:00
endif()
[libcxx] Add build/test support for the externally threaded libc++abi variant Differential revision: https://reviews.llvm.org/D27576 Reviewers: EricWF llvm-svn: 290889
2017-01-03 20:59:50 +08:00
if(NOT LIBCXX_ENABLE_THREADS)
if(LIBCXX_HAS_PTHREAD_API)
message(FATAL_ERROR "LIBCXX_HAS_PTHREAD_API can only be set to ON"
" when LIBCXX_ENABLE_THREADS is also set to ON.")
endif()
if(LIBCXX_HAS_EXTERNAL_THREAD_API)
message(FATAL_ERROR "LIBCXX_HAS_EXTERNAL_THREAD_API can only be set to ON"
" when LIBCXX_ENABLE_THREADS is also set to ON.")
endif()
[libc++] Cleanup and document <__threading_support> Summary: This patch attempts to clean up the macro configuration mess in `<__threading_support>`, specifically the mess involving external threading variants. Additionally this patch adds design documentation for `<__threading_support>` and the configuration macros it uses. The primary change in this patch is separating the idea of an "external API" provided by `<__external_threading>` and the idea of having an external threading library. Now `_LIBCPP_HAS_THREAD_API_EXTERNAL` means that libc++ should use `<__external_threading>` and that the header is expected to exist. Additionally the new macro `_LIBCPP_HAS_THREAD_LIBRARY_EXTERNAL` is now used to configure for using an "external library" with the default threading API. Reviewers: compnerd, rmaprath Subscribers: smeenai, cfe-commits, mgorny Differential Revision: https://reviews.llvm.org/D28316 llvm-svn: 291275
2017-01-07 04:05:40 +08:00
if (LIBCXX_BUILD_EXTERNAL_THREAD_LIBRARY)
message(FATAL_ERROR "LIBCXX_BUILD_EXTERNAL_THREAD_LIBRARY can only be set "
"to ON when LIBCXX_ENABLE_THREADS is also set to ON.")
endif()
[cmake] Add a config option LIBCXX_HAS_WIN32_THREAD_API for enforcing win32 threads This allows keeping libcxx using win32 threads even if a version of pthread.h is installed. This matches the existing cmake option LIBCXX_HAS_PTHREAD_API. Also add missing documentation about the internal define _LIBCPP_HAS_THREAD_API_WIN32. Differential Revision: https://reviews.llvm.org/D41764 llvm-svn: 321896
2018-01-06 04:48:29 +08:00
if (LIBCXX_HAS_WIN32_THREAD_API)
message(FATAL_ERROR "LIBCXX_HAS_WIN32_THREAD_API can only be set to ON"
" when LIBCXX_ENABLE_THREADS is also set to ON.")
endif()
[libc++] Cleanup and document <__threading_support> Summary: This patch attempts to clean up the macro configuration mess in `<__threading_support>`, specifically the mess involving external threading variants. Additionally this patch adds design documentation for `<__threading_support>` and the configuration macros it uses. The primary change in this patch is separating the idea of an "external API" provided by `<__external_threading>` and the idea of having an external threading library. Now `_LIBCPP_HAS_THREAD_API_EXTERNAL` means that libc++ should use `<__external_threading>` and that the header is expected to exist. Additionally the new macro `_LIBCPP_HAS_THREAD_LIBRARY_EXTERNAL` is now used to configure for using an "external library" with the default threading API. Reviewers: compnerd, rmaprath Subscribers: smeenai, cfe-commits, mgorny Differential Revision: https://reviews.llvm.org/D28316 llvm-svn: 291275
2017-01-07 04:05:40 +08:00
endif()
[libcxx] Fix externally-threaded shared library builds after r291275. Need to allow unresolved symbols in the dylib. This was previously done for LIBCXX_HAS_EXTERNAL_THREAD_API, but we have since split that into two with LIBCXX_BUILD_EXTERNAL_THREAD_LIBRARY being the externally-threaded variant. Also a minor CMakeLists.txt cleanup. llvm-svn: 291433
2017-01-09 18:38:56 +08:00
if (LIBCXX_HAS_EXTERNAL_THREAD_API)
if (LIBCXX_BUILD_EXTERNAL_THREAD_LIBRARY)
message(FATAL_ERROR "The options LIBCXX_BUILD_EXTERNAL_THREAD_LIBRARY and "
"LIBCXX_HAS_EXTERNAL_THREAD_API cannot both be ON at "
"the same time")
endif()
if (LIBCXX_HAS_PTHREAD_API)
message(FATAL_ERROR "The options LIBCXX_HAS_EXTERNAL_THREAD_API"
"and LIBCXX_HAS_PTHREAD_API cannot be both"
"set to ON at the same time.")
endif()
[cmake] Add a config option LIBCXX_HAS_WIN32_THREAD_API for enforcing win32 threads This allows keeping libcxx using win32 threads even if a version of pthread.h is installed. This matches the existing cmake option LIBCXX_HAS_PTHREAD_API. Also add missing documentation about the internal define _LIBCPP_HAS_THREAD_API_WIN32. Differential Revision: https://reviews.llvm.org/D41764 llvm-svn: 321896
2018-01-06 04:48:29 +08:00
if (LIBCXX_HAS_WIN32_THREAD_API)
message(FATAL_ERROR "The options LIBCXX_HAS_EXTERNAL_THREAD_API"
"and LIBCXX_HAS_WIN32_THREAD_API cannot be both"
"set to ON at the same time.")
endif()
endif()
if (LIBCXX_HAS_PTHREAD_API)
if (LIBCXX_HAS_WIN32_THREAD_API)
message(FATAL_ERROR "The options LIBCXX_HAS_PTHREAD_API"
"and LIBCXX_HAS_WIN32_THREAD_API cannot be both"
"set to ON at the same time.")
endif()
[libcxx] Introduce an externally-threaded libc++ variant. This patch further decouples libc++ from pthread, allowing libc++ to be built against other threading systems. There are two main use cases: - Building libc++ against a thread library other than pthreads. - Building libc++ with an "external" thread API, allowing a separate library to provide the implementation of that API. The two use cases are quite similar, the second one being sligtly more de-coupled than the first. The cmake option LIBCXX_HAS_EXTERNAL_THREAD_API enables both kinds of builds. One needs to place an <__external_threading> header file containing an implementation of the "libc++ thread API" declared in the <__threading_support> header. For the second use case, the implementation of the libc++ thread API can delegate to a custom "external" thread API where the implementation of this external API is provided in a seperate library. This mechanism allows toolchain vendors to distribute a build of libc++ with a custom thread-porting-layer API (which is the "external" API above), platform vendors (recipients of the toolchain/libc++) are then required to provide their implementation of this API to be linked with (end-user) C++ programs. Note that the second use case still requires establishing the basic types that get passed between the external thread library and the libc++ library (e.g. __libcpp_mutex_t). These cannot be opaque pointer types (libc++ sources won't compile otherwise). It should also be noted that the second use case can have a slight performance penalty; as all the thread constructs need to cross a library boundary through an additional function call. When the header <__external_threading> is omitted, libc++ is built with the "libc++ thread API" (declared in <__threading_support>) as the "external" thread API (basic types are pthread based). An implementation (pthread based) of this API is provided in test/support/external_threads.cpp, which is built into a separate DSO and linked in when running the libc++ test suite. A test run therefore demonstrates the second use case (less the intermediate custom API). Differential revision: https://reviews.llvm.org/D21968 Reviewers: bcraig, compnerd, EricWF, mclow.lists llvm-svn: 281179
2016-09-12 05:46:40 +08:00
endif()
Reapply working parts of CMake cleanup. This patch adds the working parts of r243503. The difference with this patch is that it doesn't include the HandleLLVMOptions.cmake file. llvm-svn: 243698
2015-07-31 06:30:34 +08:00
# Ensure LLVM_USE_SANITIZER is not specified when LIBCXX_GENERATE_COVERAGE
# is ON.
if (LLVM_USE_SANITIZER AND LIBCXX_GENERATE_COVERAGE)
message(FATAL_ERROR "LLVM_USE_SANITIZER cannot be used with LIBCXX_GENERATE_COVERAGE")
endif()
# Set LIBCXX_BUILD_32_BITS to (LIBCXX_BUILD_32_BITS OR LLVM_BUILD_32_BITS)
# and check that we can build with 32 bits if requested.
if (CMAKE_SIZEOF_VOID_P EQUAL 8 AND NOT WIN32)
if (LIBCXX_BUILD_32_BITS AND NOT LLVM_BUILD_32_BITS) # Don't duplicate the output from LLVM
message(STATUS "Building 32 bits executables and libraries.")
endif()
elseif(LIBCXX_BUILD_32_BITS)
message(FATAL_ERROR "LIBCXX_BUILD_32_BITS=ON is not supported on this platform.")
endif()
[libc++][CMake] Allow merging libc++abi.a into libc++ even on Apple platforms Summary: I can't see a good reason to disallow this, even though it isn't the standard way we build libc++ for Apple platforms. Making this work on Apple platforms requires using different flags for --whole-archive and removing the -D flag when running `ar` to merge archives because that flag isn't supported by the `ar` shipped on Apple platforms. This shouldn't be an issue since the -D option appears to be enabled by default in GNU `ar`. Reviewers: phosek, EricWF, serge-sans-paille Subscribers: mgorny, christof, jkorous, dexonsmith, libcxx-commits Differential Revision: https://reviews.llvm.org/D59513 llvm-svn: 356903
2019-03-25 22:56:29 +08:00
# Warn users that LIBCXX_ENABLE_STATIC_ABI_LIBRARY is an experimental option.
[libcxx] Add support for linking libc++ against a static ABI library. Summary: This patch add the CMake option `LIBCXX_ENABLE_STATIC_ABI_LIBRARY` which, when enabled, will link libc++ against the static version of the ABI library. Reviewers: mclow.lists, jroelofs, danalbert Reviewed By: danalbert Subscribers: compnerd, cfe-commits Differential Revision: http://reviews.llvm.org/D8017 llvm-svn: 231076
2015-03-03 23:59:51 +08:00
if (LIBCXX_ENABLE_STATIC_ABI_LIBRARY)
[libc++][CMake] Allow merging libc++abi.a into libc++ even on Apple platforms Summary: I can't see a good reason to disallow this, even though it isn't the standard way we build libc++ for Apple platforms. Making this work on Apple platforms requires using different flags for --whole-archive and removing the -D flag when running `ar` to merge archives because that flag isn't supported by the `ar` shipped on Apple platforms. This shouldn't be an issue since the -D option appears to be enabled by default in GNU `ar`. Reviewers: phosek, EricWF, serge-sans-paille Subscribers: mgorny, christof, jkorous, dexonsmith, libcxx-commits Differential Revision: https://reviews.llvm.org/D59513 llvm-svn: 356903
2019-03-25 22:56:29 +08:00
message(WARNING "LIBCXX_ENABLE_STATIC_ABI_LIBRARY is an experimental option")
Revert "Temporarily revert "build: use `find_package(Python3)` if available"" This reverts commit 35edd704e0fda09e8e634515c0b451d4a8b6b914. Revert the revert and extend the patch further to account for the use of the `PYTHONINTERP_FOUND`.
2020-04-29 09:37:28 +08:00
if (LIBCXX_ENABLE_STATIC AND NOT Python3_EXECUTABLE)
Make LIBCXX_ENABLE_STATIC_ABI_LIBRARY merge libc++.a and libc++abi.a llvm-svn: 287373
2016-11-19 03:53:45 +08:00
message(FATAL_ERROR "LIBCXX_ENABLE_STATIC_ABI_LIBRARY requires python but it was not found.")
endif()
[libcxx] Add support for linking libc++ against a static ABI library. Summary: This patch add the CMake option `LIBCXX_ENABLE_STATIC_ABI_LIBRARY` which, when enabled, will link libc++ against the static version of the ABI library. Reviewers: mclow.lists, jroelofs, danalbert Reviewed By: danalbert Subscribers: compnerd, cfe-commits Differential Revision: http://reviews.llvm.org/D8017 llvm-svn: 231076
2015-03-03 23:59:51 +08:00
endif()
[libcxx] Make it drastically simpler to link libc++. Summary: Currently on most platforms you have to manually link the c++ abi library used with libc++ whenever you use libc++. So your typical libc++ command like invocation might look like: ``` clang++ -stdlib=libc++ foo.cpp -lc++abi ``` Having to manually link `libc++abi.so` makes it harder for libc++ to be used generically. This patch fixes that by generating a linker script for `libc++.so` that correctly links the ABI library. On linux the linker script for libc++abi would look like: ``` # libc++.so INPUT(libc++.so.1 -lc++abi) ``` With the linker script you can now use libc++ using only `-stdlib=libc++`. This is the technique that is used on FreeBSD in ordered to link cxxrt and I think it's the best approach to make our users lives simpler. The CMake option used to enable this is `LIBCXX_ENABLE_ABI_LINKER_SCRIPT`. In future I would like to enable this by default on all platforms except for Darwin. Reviewers: mclow.lists, danalbert, rsmith, jroelofs, EricWF Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D12508 llvm-svn: 250319
2015-10-15 03:54:03 +08:00
if (LIBCXX_ENABLE_ABI_LINKER_SCRIPT)
if (APPLE)
message(FATAL_ERROR "LIBCXX_ENABLE_ABI_LINKER_SCRIPT cannot be used on APPLE targets")
endif()
Disable LIBCXX_ENABLE_ABI_LINKER_SCRIPT for static library builds. This option is geared towards shared library builds and causes static library builds to fail if not explicitly disabled. This patch fixes PR27706: https://llvm.org/bugs/show_bug.cgi?id=27706 Thanks rgoodfel@isi.edu for the catch. llvm-svn: 269585
2016-05-15 07:58:11 +08:00
if (NOT LIBCXX_ENABLE_SHARED)
message(FATAL_ERROR "LIBCXX_ENABLE_ABI_LINKER_SCRIPT is only available for shared library builds.")
endif()
[libcxx] Make it drastically simpler to link libc++. Summary: Currently on most platforms you have to manually link the c++ abi library used with libc++ whenever you use libc++. So your typical libc++ command like invocation might look like: ``` clang++ -stdlib=libc++ foo.cpp -lc++abi ``` Having to manually link `libc++abi.so` makes it harder for libc++ to be used generically. This patch fixes that by generating a linker script for `libc++.so` that correctly links the ABI library. On linux the linker script for libc++abi would look like: ``` # libc++.so INPUT(libc++.so.1 -lc++abi) ``` With the linker script you can now use libc++ using only `-stdlib=libc++`. This is the technique that is used on FreeBSD in ordered to link cxxrt and I think it's the best approach to make our users lives simpler. The CMake option used to enable this is `LIBCXX_ENABLE_ABI_LINKER_SCRIPT`. In future I would like to enable this by default on all platforms except for Darwin. Reviewers: mclow.lists, danalbert, rsmith, jroelofs, EricWF Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D12508 llvm-svn: 250319
2015-10-15 03:54:03 +08:00
endif()
[CMake] Don't generate linker script only when shared library isn't statically linked Since r337668, we support statically linking dependencies only to shared or static library. However, that change hasn't updated the check whether to generate a linker script. We shouldn't generate linker script only in the case when we aren't statically linked ABI into the shared library. Differential Revision: https://reviews.llvm.org/D49834 llvm-svn: 338006
2018-07-26 13:10:24 +08:00
if (LIBCXX_STATICALLY_LINK_ABI_IN_SHARED_LIBRARY AND LIBCXX_ENABLE_ABI_LINKER_SCRIPT)
[libcxx] Make it drastically simpler to link libc++. Summary: Currently on most platforms you have to manually link the c++ abi library used with libc++ whenever you use libc++. So your typical libc++ command like invocation might look like: ``` clang++ -stdlib=libc++ foo.cpp -lc++abi ``` Having to manually link `libc++abi.so` makes it harder for libc++ to be used generically. This patch fixes that by generating a linker script for `libc++.so` that correctly links the ABI library. On linux the linker script for libc++abi would look like: ``` # libc++.so INPUT(libc++.so.1 -lc++abi) ``` With the linker script you can now use libc++ using only `-stdlib=libc++`. This is the technique that is used on FreeBSD in ordered to link cxxrt and I think it's the best approach to make our users lives simpler. The CMake option used to enable this is `LIBCXX_ENABLE_ABI_LINKER_SCRIPT`. In future I would like to enable this by default on all platforms except for Darwin. Reviewers: mclow.lists, danalbert, rsmith, jroelofs, EricWF Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D12508 llvm-svn: 250319
2015-10-15 03:54:03 +08:00
message(FATAL_ERROR "Conflicting options given.
LIBCXX_ENABLE_STATIC_ABI_LIBRARY cannot be specified with
LIBCXX_ENABLE_ABI_LINKER_SCRIPT")
endif()
[libc++] Clarify names of ABI forcing macros Make it clear that these are intended only to force a specific ABI when the autodetection would give the wrong result by renaming the cmake options and adding separate forcing macros, as suggested by EricWF in the post-commit review of r314949 and further discussed on IRC. llvm-svn: 314965
2017-10-05 10:18:08 +08:00
if (LIBCXX_ABI_FORCE_ITANIUM AND LIBCXX_ABI_FORCE_MICROSOFT)
message(FATAL_ERROR "Only one of LIBCXX_ABI_FORCE_ITANIUM and LIBCXX_ABI_FORCE_MICROSOFT can be specified.")
[libc++] Allow users to explicitly specify ABI libc++'s current heuristic for detecting Itanium vs. Microsoft ABI falls short in some cases. For example, it will detect windows-itanium targets as using the Microsoft ABI, since they set `_MSC_VER` (for compatibility with Microsoft headers). Leave the current heuristic in place by default but also allow users to explicitly specify the ABI if need be. llvm-svn: 314949
2017-10-05 07:44:38 +08:00
endif ()
Add CMake build and fix major Linux blockers. llvm-svn: 121510
2010-12-11 03:47:54 +08:00
#===============================================================================
# Configure System
#===============================================================================
[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
# TODO: Projects that depend on libc++ should use LIBCXX_GENERATED_INCLUDE_DIR
# instead of hard-coding include/c++/v1.
Support for multiarch runtimes layout This change adds a support for multiarch style runtimes layout, so in addition to the existing layout where runtimes get installed to: lib/clang/$version/lib/$os Clang now allows runtimes to be installed to: lib/clang/$version/$target/lib This also includes libc++, libc++abi and libunwind; today those are assumed to be in Clang library directory built for host, with the new layout it is possible to install libc++, libc++abi and libunwind into the runtime directory built for different targets. The use of new layout is enabled by setting the LLVM_ENABLE_RUNTIME_TARGET_DIR CMake variable and is supported by both projects and runtimes layouts. The runtimes CMake build has been further modified to use the new layout when building runtimes for multiple targets. Differential Revision: https://reviews.llvm.org/D45604 llvm-svn: 335809
2018-06-28 11:11:52 +08:00
if(LLVM_ENABLE_PER_TARGET_RUNTIME_DIR AND NOT APPLE)
[libcxx] Stop using use c++ subdirectory for libc++ library The new layout more closely matches the layout used by other compilers. This is only used when LLVM_ENABLE_PER_TARGET_RUNTIME_DIR is enabled. Differential Revision: https://reviews.llvm.org/D100869
2021-04-17 12:33:18 +08:00
set(LIBCXX_LIBRARY_DIR ${LLVM_LIBRARY_OUTPUT_INTDIR}/${LLVM_DEFAULT_TARGET_TRIPLE})
[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
set(LIBCXX_GENERATED_INCLUDE_DIR "${LLVM_BINARY_DIR}/include/c++/v1")
[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(LIBCXX_GENERATED_INCLUDE_TARGET_DIR "${LLVM_BINARY_DIR}/include/${LLVM_DEFAULT_TARGET_TRIPLE}/c++/v1")
[libcxx] Stop using use c++ subdirectory for libc++ library The new layout more closely matches the layout used by other compilers. This is only used when LLVM_ENABLE_PER_TARGET_RUNTIME_DIR is enabled. Differential Revision: https://reviews.llvm.org/D100869
2021-04-17 12:33:18 +08:00
set(LIBCXX_INSTALL_LIBRARY_DIR lib${LLVM_LIBDIR_SUFFIX}/${LLVM_DEFAULT_TARGET_TRIPLE})
[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(LIBCXX_INSTALL_INCLUDE_DIR "include/c++/v1")
set(LIBCXX_INSTALL_INCLUDE_TARGET_DIR "include/${LLVM_DEFAULT_TARGET_TRIPLE}/c++/v1")
[runtimes] Move libunwind, libc++abi and libc++ to lib/$target/c++ and include/c++ This change is a consequence of the discussion in "RFC: Place libs in Clang-dedicated directories", specifically the suggestion that libunwind, libc++abi and libc++ shouldn't be using Clang resource directory. Tools like clangd make this assumption, but this is currently not true for the LLVM_ENABLE_PER_TARGET_RUNTIME_DIR build. This change addresses that by moving the output of these libraries to lib/$target/c++ and include/c++ directories, leaving resource directory only for compiler-rt runtimes and Clang builtin headers. Differential Revision: https://reviews.llvm.org/D59168 llvm-svn: 361432
2019-05-23 05:08:33 +08:00
if(LIBCXX_LIBDIR_SUBDIR)
string(APPEND LIBCXX_LIBRARY_DIR /${LIBCXX_LIBDIR_SUBDIR})
string(APPEND LIBCXX_INSTALL_LIBRARY_DIR /${LIBCXX_LIBDIR_SUBDIR})
endif()
Support for multiarch runtimes layout This change adds a support for multiarch style runtimes layout, so in addition to the existing layout where runtimes get installed to: lib/clang/$version/lib/$os Clang now allows runtimes to be installed to: lib/clang/$version/$target/lib This also includes libc++, libc++abi and libunwind; today those are assumed to be in Clang library directory built for host, with the new layout it is possible to install libc++, libc++abi and libunwind into the runtime directory built for different targets. The use of new layout is enabled by setting the LLVM_ENABLE_RUNTIME_TARGET_DIR CMake variable and is supported by both projects and runtimes layouts. The runtimes CMake build has been further modified to use the new layout when building runtimes for multiple targets. Differential Revision: https://reviews.llvm.org/D45604 llvm-svn: 335809
2018-06-28 11:11:52 +08:00
elseif(LLVM_LIBRARY_OUTPUT_INTDIR)
[libcxx][CMake] Set library dir when built under runtimes/ This will put libraries into the build root's lib/ directory by default. Differential Revision: https://reviews.llvm.org/D32736 llvm-svn: 302117
2017-05-04 14:02:50 +08:00
set(LIBCXX_LIBRARY_DIR ${LLVM_LIBRARY_OUTPUT_INTDIR})
[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
set(LIBCXX_GENERATED_INCLUDE_DIR "${LLVM_BINARY_DIR}/include/c++/v1")
[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(LIBCXX_GENERATED_INCLUDE_TARGET_DIR "${LIBCXX_GENERATED_INCLUDE_DIR}")
[runtimes] Move libunwind, libc++abi and libc++ to lib/$target/c++ and include/c++ This change is a consequence of the discussion in "RFC: Place libs in Clang-dedicated directories", specifically the suggestion that libunwind, libc++abi and libc++ shouldn't be using Clang resource directory. Tools like clangd make this assumption, but this is currently not true for the LLVM_ENABLE_PER_TARGET_RUNTIME_DIR build. This change addresses that by moving the output of these libraries to lib/$target/c++ and include/c++ directories, leaving resource directory only for compiler-rt runtimes and Clang builtin headers. Differential Revision: https://reviews.llvm.org/D59168 llvm-svn: 361432
2019-05-23 05:08:33 +08:00
set(LIBCXX_INSTALL_LIBRARY_DIR lib${LIBCXX_LIBDIR_SUFFIX})
[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(LIBCXX_INSTALL_INCLUDE_DIR "include/c++/v1")
set(LIBCXX_INSTALL_INCLUDE_TARGET_DIR "${LIBCXX_INSTALL_INCLUDE_DIR}")
[libcxx][CMake] Set library dir when built under runtimes/ This will put libraries into the build root's lib/ directory by default. Differential Revision: https://reviews.llvm.org/D32736 llvm-svn: 302117
2017-05-04 14:02:50 +08:00
else()
set(LIBCXX_LIBRARY_DIR ${CMAKE_BINARY_DIR}/lib${LIBCXX_LIBDIR_SUFFIX})
[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
set(LIBCXX_GENERATED_INCLUDE_DIR "${CMAKE_BINARY_DIR}/include/c++/v1")
[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(LIBCXX_GENERATED_INCLUDE_TARGET_DIR "${LIBCXX_GENERATED_INCLUDE_DIR}")
[runtimes] Move libunwind, libc++abi and libc++ to lib/$target/c++ and include/c++ This change is a consequence of the discussion in "RFC: Place libs in Clang-dedicated directories", specifically the suggestion that libunwind, libc++abi and libc++ shouldn't be using Clang resource directory. Tools like clangd make this assumption, but this is currently not true for the LLVM_ENABLE_PER_TARGET_RUNTIME_DIR build. This change addresses that by moving the output of these libraries to lib/$target/c++ and include/c++ directories, leaving resource directory only for compiler-rt runtimes and Clang builtin headers. Differential Revision: https://reviews.llvm.org/D59168 llvm-svn: 361432
2019-05-23 05:08:33 +08:00
set(LIBCXX_INSTALL_LIBRARY_DIR lib${LIBCXX_LIBDIR_SUFFIX})
[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(LIBCXX_INSTALL_INCLUDE_DIR "include/c++/v1")
set(LIBCXX_INSTALL_INCLUDE_TARGET_DIR "${LIBCXX_INSTALL_INCLUDE_DIR}")
[libcxx][CMake] Set library dir when built under runtimes/ This will put libraries into the build root's lib/ directory by default. Differential Revision: https://reviews.llvm.org/D32736 llvm-svn: 302117
2017-05-04 14:02:50 +08:00
endif()
Support for multiarch runtimes layout This change adds a support for multiarch style runtimes layout, so in addition to the existing layout where runtimes get installed to: lib/clang/$version/lib/$os Clang now allows runtimes to be installed to: lib/clang/$version/$target/lib This also includes libc++, libc++abi and libunwind; today those are assumed to be in Clang library directory built for host, with the new layout it is possible to install libc++, libc++abi and libunwind into the runtime directory built for different targets. The use of new layout is enabled by setting the LLVM_ENABLE_RUNTIME_TARGET_DIR CMake variable and is supported by both projects and runtimes layouts. The runtimes CMake build has been further modified to use the new layout when building runtimes for multiple targets. Differential Revision: https://reviews.llvm.org/D45604 llvm-svn: 335809
2018-06-28 11:11:52 +08:00
Improve CMake and LIT support for Windows This patch contains multiple cleanups and fixes to better support building on Windows. * [Test] Fix handling of library runtime search paths by correctly adding them to the PATH variable when running the tests. * [Test] Don't explicitly force "--target=i686-pc-windows" when running the test suite. Clang++ seems to deduce the correct target. * [Test] Fix `.sh.cpp` tests on Windows by properly escaping flags used in shell commands. Specifically windows style paths which included spaces were causing these tests to fail. * [CMake] Add "vcruntime" to the list of supported C++ ABI libraries in CMake, and teach the test suite how to handle it. For now libc++ defaults to using "vcruntime" on Windows except when libc++abi is in tree; That is probably a bug and should be changed to always use vcruntime, at least for now. * [Misc] Move the "c++-build" include directory to the libc++ binary dir instead of the top level project dir and rename it "c++build". This is just misc cleanup. Libc++ shouldn't be creating internal build files and directories at the top-level projects root. * [Misc] Build type_info's destructor when building for MSVC. This is a temporary work around to prevent link errors until we have a proper type_info implementation. llvm-svn: 292157
2017-01-17 04:47:35 +08:00
file(MAKE_DIRECTORY "${LIBCXX_BINARY_INCLUDE_DIR}")
[libcxx] Teach libcxx's lit configuration new ways to find lit.site.cfg Summary: Currently to run tests in tree you need to symlink the lit.site.cfg file generated by the cmake build into the source tree, and teach your VCS to ignore it. This allows the user to specify where to find the lit.site.cfg file two different ways: * lit_site_config lit parameter * LIT_SITE_CONFIG enviroment variable. example usage: ``` lit -sv --param=libcxx_site_config=path/to/libcxx-build/test/lit.site.cfg path/to/tests ``` Or ``` export LIBCXX_SITE_CONFIG=path/to/libcxx-build/test/lit.site.cfg lit -sv path/to/tests ``` The command line parameter will override the environment variable. If neither options are present a warning is issued and the `lit.cfg` file is loaded directly. Reviewers: mclow.lists, jroelofs, danalbert Reviewed By: danalbert Subscribers: ddunbar, cfe-commits Differential Revision: http://reviews.llvm.org/D6255 llvm-svn: 224671
2014-12-20 11:16:55 +08:00
Reapply working parts of CMake cleanup. This patch adds the working parts of r243503. The difference with this patch is that it doesn't include the HandleLLVMOptions.cmake file. llvm-svn: 243698
2015-07-31 06:30:34 +08:00
set(CMAKE_ARCHIVE_OUTPUT_DIRECTORY ${LIBCXX_LIBRARY_DIR})
set(CMAKE_LIBRARY_OUTPUT_DIRECTORY ${LIBCXX_LIBRARY_DIR})
[libc++] Explicitly set output directory for DLL DLLs on Windows are treated as runtime targets. Explicitly set the output directory for them, to be consistent with other platforms. llvm-svn: 300206
2017-04-14 00:27:38 +08:00
set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${LIBCXX_LIBRARY_DIR})
Reapply working parts of CMake cleanup. This patch adds the working parts of r243503. The difference with this patch is that it doesn't include the HandleLLVMOptions.cmake file. llvm-svn: 243698
2015-07-31 06:30:34 +08:00
[libcxx] Refactor CMakeLists.txt handling of compile and link flags to suppress warnings. Summary: Currently we have 5 variables that are used to specify options for building libcxx 1. `LIBCXX_CXX_FEATURE_FLAGS` 2. `LIBCXX_CXX_WARNING_FLAGS` 3. `LIBCXX_CXX_REQUIRED_FLAGS` 4. `compile_flags` (in libcxx/lib) 5. `link_flags` (in libcxx/lib) The first three all get put into `CMAKE_CXX_FLAGS`. This changes the way flags are handled by only using 3 different options: 1. `LIBCXX_CXX_FLAGS` - general compile and link flags. 2. `LIBCXX_COMPILE_FLAGS` - compile only flags. 3. `LIBCXX_LINK_FLAGS` - link only flags. This patch also removes the warning about `-nostdinc++` being unused during linking. Reviewers: mclow.lists, danalbert Reviewed By: danalbert Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D6277 llvm-svn: 222080
2014-11-15 14:26:30 +08:00
# Declare libc++ configuration variables.
# They are intended for use as follows:
# LIBCXX_CXX_FLAGS: General flags for both the compiler and linker.
# LIBCXX_COMPILE_FLAGS: Compile only flags.
# LIBCXX_LINK_FLAGS: Linker only flags.
Fix linker script generation for in-tree builds llvm-svn: 283700
2016-10-10 05:34:03 +08:00
# LIBCXX_LIBRARIES: libraries libc++ is linked to.
[libcxx] Refactor CMakeLists.txt handling of compile and link flags to suppress warnings. Summary: Currently we have 5 variables that are used to specify options for building libcxx 1. `LIBCXX_CXX_FEATURE_FLAGS` 2. `LIBCXX_CXX_WARNING_FLAGS` 3. `LIBCXX_CXX_REQUIRED_FLAGS` 4. `compile_flags` (in libcxx/lib) 5. `link_flags` (in libcxx/lib) The first three all get put into `CMAKE_CXX_FLAGS`. This changes the way flags are handled by only using 3 different options: 1. `LIBCXX_CXX_FLAGS` - general compile and link flags. 2. `LIBCXX_COMPILE_FLAGS` - compile only flags. 3. `LIBCXX_LINK_FLAGS` - link only flags. This patch also removes the warning about `-nostdinc++` being unused during linking. Reviewers: mclow.lists, danalbert Reviewed By: danalbert Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D6277 llvm-svn: 222080
2014-11-15 14:26:30 +08:00
set(LIBCXX_COMPILE_FLAGS "")
set(LIBCXX_LINK_FLAGS "")
Reapply working parts of CMake cleanup. This patch adds the working parts of r243503. The difference with this patch is that it doesn't include the HandleLLVMOptions.cmake file. llvm-svn: 243698
2015-07-31 06:30:34 +08:00
set(LIBCXX_LIBRARIES "")
[libcxx] Refactor CMakeLists.txt handling of compile and link flags to suppress warnings. Summary: Currently we have 5 variables that are used to specify options for building libcxx 1. `LIBCXX_CXX_FEATURE_FLAGS` 2. `LIBCXX_CXX_WARNING_FLAGS` 3. `LIBCXX_CXX_REQUIRED_FLAGS` 4. `compile_flags` (in libcxx/lib) 5. `link_flags` (in libcxx/lib) The first three all get put into `CMAKE_CXX_FLAGS`. This changes the way flags are handled by only using 3 different options: 1. `LIBCXX_CXX_FLAGS` - general compile and link flags. 2. `LIBCXX_COMPILE_FLAGS` - compile only flags. 3. `LIBCXX_LINK_FLAGS` - link only flags. This patch also removes the warning about `-nostdinc++` being unused during linking. Reviewers: mclow.lists, danalbert Reviewed By: danalbert Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D6277 llvm-svn: 222080
2014-11-15 14:26:30 +08:00
[libcxx] Allow target flags to affect CMake configuration tests Summary: This patch changes the libc++ CMake so that it adds certain target flags like '-m32' or '--gcc-toolchain' before including config-ix.cmake. Since these flags can affect things like check_library_exists([...]) they needed to be added before the tests are performed. This patch fixes: https://llvm.org/bugs/show_bug.cgi?id=24322 Reviewers: danalbert, jroelofs, bcraig, compnerd Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D20887 llvm-svn: 271460
2016-06-02 09:10:08 +08:00
# Include macros for adding and removing libc++ flags.
include(HandleLibcxxFlags)
# Target flags ================================================================
# These flags get added to CMAKE_CXX_FLAGS and CMAKE_C_FLAGS so that
# 'config-ix' use them during feature checks. It also adds them to both
# 'LIBCXX_COMPILE_FLAGS' and 'LIBCXX_LINK_FLAGS'
add_target_flags_if(LIBCXX_BUILD_32_BITS "-m32")
[CMake] Support CMake variables for setting target, sysroot and toolchain CMake has a standard way of setting target triple, sysroot and external toolchain through CMAKE_<LANG>_COMPILER_TARGET, CMAKE_SYSROOT and CMAKE_<LANG>_COMPILER_EXTERNAL_TOOLCHAIN. These are turned into corresponding --target=, --sysroot= and --gcc-toolchain= variables add included appended to CMAKE_<LANG>_FLAGS. libunwind, libc++abi, libc++ provides their own mechanism through <PROJECT>_TARGET_TRIPLE, <PROJECT>_SYSROOT and <PROJECT>_GCC_TOOLCHAIN variables. These are also passed to lit via lit.site.cfg, and lit config uses these to set the corresponding compiler flags when building tessts. This means that there are two different ways of setting target, sysroot and toolchain, but only one is properly supported in lit. This change extends CMake build for libunwind, libc++abi and libc++ to also support the CMake variables in addition to project specific ones in lit. Differential Revision: https://reviews.llvm.org/D57670 llvm-svn: 353084
2019-02-05 04:02:26 +08:00
if(LIBCXX_TARGET_TRIPLE)
add_target_flags("--target=${LIBCXX_TARGET_TRIPLE}")
elseif(CMAKE_CXX_COMPILER_TARGET)
set(LIBCXX_TARGET_TRIPLE "${CMAKE_CXX_COMPILER_TARGET}")
endif()
if(LIBCXX_SYSROOT)
add_target_flags("--sysroot=${LIBCXX_SYSROOT}")
elseif(CMAKE_SYSROOT)
set(LIBCXX_SYSROOT "${CMAKE_SYSROOT}")
endif()
if(LIBCXX_GCC_TOOLCHAIN)
add_target_flags("--gcc-toolchain=${LIBCXX_GCC_TOOLCHAIN}")
elseif(CMAKE_CXX_COMPILER_EXTERNAL_TOOLCHAIN)
set(LIBCXX_GCC_TOOLCHAIN "${CMAKE_CXX_COMPILER_EXTERNAL_TOOLCHAIN}")
endif()
if(LIBCXX_TARGET_TRIPLE)
Fix GCC libc++abi build llvm-svn: 286783
2016-11-14 06:27:00 +08:00
set(TARGET_TRIPLE "${LIBCXX_TARGET_TRIPLE}")
endif()
[libcxx] Allow target flags to affect CMake configuration tests Summary: This patch changes the libc++ CMake so that it adds certain target flags like '-m32' or '--gcc-toolchain' before including config-ix.cmake. Since these flags can affect things like check_library_exists([...]) they needed to be added before the tests are performed. This patch fixes: https://llvm.org/bugs/show_bug.cgi?id=24322 Reviewers: danalbert, jroelofs, bcraig, compnerd Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D20887 llvm-svn: 271460
2016-06-02 09:10:08 +08:00
Fix build regression caused by not defining ABI library macros llvm-svn: 222085
2014-11-16 01:25:23 +08:00
# Configure compiler.
include(config-ix)
Reapply working parts of CMake cleanup. This patch adds the working parts of r243503. The difference with this patch is that it doesn't include the HandleLLVMOptions.cmake file. llvm-svn: 243698
2015-07-31 06:30:34 +08:00
[libcxx] Add code coverage configuration to CMake and LIT. Summary: This patch adds configuration to CMake and LIT for running the libc++ test-suite to generate code coverage. To use code coverage use following instructions. * Find the clang resource dir using `$CXX -print-search-dirs`. Let <library-dir> be the first library search directory. * `cmake <regular-options> -DLIBCXX_GENERATE_COVERAGE=ON -DLIBCXX_COVERAGE_LIBRARY=<library-dir>/lib/<platform>/libclang_rt.profile.a <source>` * `make cxx` * `make check-libcxx` * `make generate-libcxx-coverage` The reason I want this patch upstreamed is so I can setup a bot that generates code coverage and posts in online for every revision. Reviewers: mclow.lists, jroelofs, danalbert Reviewed By: danalbert Differential Revision: http://reviews.llvm.org/D8716 llvm-svn: 233669
2015-03-31 12:15:45 +08:00
# Configure coverage options.
if (LIBCXX_GENERATE_COVERAGE)
include(CodeCoverage)
set(CMAKE_BUILD_TYPE "COVERAGE" CACHE STRING "" FORCE)
endif()
Fix build regression caused by not defining ABI library macros llvm-svn: 222085
2014-11-16 01:25:23 +08:00
Reapply working parts of CMake cleanup. This patch adds the working parts of r243503. The difference with this patch is that it doesn't include the HandleLLVMOptions.cmake file. llvm-svn: 243698
2015-07-31 06:30:34 +08:00
string(TOUPPER "${CMAKE_BUILD_TYPE}" uppercase_CMAKE_BUILD_TYPE)
[libc++][CMake] Use debug MSVC runtimes when libc++ is built in debug mode 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
2017-01-14 15:54:39 +08:00
if (uppercase_CMAKE_BUILD_TYPE STREQUAL "DEBUG")
set(LIBCXX_DEBUG_BUILD ON)
else()
set(LIBCXX_DEBUG_BUILD OFF)
endif()
Reapply working parts of CMake cleanup. This patch adds the working parts of r243503. The difference with this patch is that it doesn't include the HandleLLVMOptions.cmake file. llvm-svn: 243698
2015-07-31 06:30:34 +08:00
Fix build regression caused by not defining ABI library macros llvm-svn: 222085
2014-11-16 01:25:23 +08:00
#===============================================================================
# Setup Compiler Flags
#===============================================================================
libc++: fix typo llvm-svn: 262771
2016-03-05 22:22:02 +08:00
include(HandleLibCXXABI) # Setup the ABI library flags
[libcxx] Cleanup CMake configuration and integrate with LLVM Summary: This patch contains the following changes: 1. Require that libc++ can find a LLVM source directory. This is done the same way as `libc++abi` currently does. 2. Cleanup ugly configuration code in CMakeLists.txt by using `add_flags`, `add_flags_if`, and `add_flags_if_supported` macros. The goals for this patch are: 1. Help libc++ be more consistent with how LLVM handles CMake options (see PR23670 PR23671). 2. Make it easier to use sanitizers using the `LLVM_USE_SANITIZER` option. 3. Make libc++'s CMakeLists.txt file easier to understand and change. 4. Move towards allowing libc++ to create Sphinx documentation (see http://efcs.ca/libcxx-docs). 5. Move towards allowing libc++ to use other LLVM utilities such as `not` and `FileCheck`. Reviewers: mclow.lists, jroelofs, danalbert Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D11308 llvm-svn: 243503
2015-07-29 08:03:51 +08:00
[cmake] Strip possibly-inherited compiler flags in in-tree build only Strip the set of flags (including debug defs, -m32) that could be inherited from top-level LLVM build only when in-tree build is performed. This prevents libcxx from confusingly and undesiredly stripping user-supplied flags e.g. when performing packaging system controlled multi-ABI build. Otherwise, in order to perform 32-bit builds the build scripts would have to use LIBCXX_BUILD_32_BITS. However, -m32 is only one of the many different ABI flags for different targets, and it really makes no sense to add separate CMake options for each possible -m* flag and then keep a mapping from well-known flags to the custom CMake options. Differential Revision: https://reviews.llvm.org/D24809 llvm-svn: 282475
2016-09-27 15:55:26 +08:00
if (NOT LIBCXX_STANDALONE_BUILD)
# Remove flags that may have snuck in.
remove_flags(-DNDEBUG -UNDEBUG -D_DEBUG
Don't strip -m32 from the user provide command line flags. This fixes the compiler-rt 32 bit sanitizer build llvm-svn: 292291
2017-01-18 07:27:56 +08:00
-lc++abi)
[cmake] Strip possibly-inherited compiler flags in in-tree build only Strip the set of flags (including debug defs, -m32) that could be inherited from top-level LLVM build only when in-tree build is performed. This prevents libcxx from confusingly and undesiredly stripping user-supplied flags e.g. when performing packaging system controlled multi-ABI build. Otherwise, in order to perform 32-bit builds the build scripts would have to use LIBCXX_BUILD_32_BITS. However, -m32 is only one of the many different ABI flags for different targets, and it really makes no sense to add separate CMake options for each possible -m* flag and then keep a mapping from well-known flags to the custom CMake options. Differential Revision: https://reviews.llvm.org/D24809 llvm-svn: 282475
2016-09-27 15:55:26 +08:00
endif()
Fix all the CMake code that can only handle -stdlib= but not --stdlib= There are several places in LLVM's CMake setup that try to remove the `stdlib=...` flag from the CMake flags. All this code however only considered the `-stdlib=` variant of the flag but not the alternative spelling with a double dash. This causes that when one adds `--stdlib=...` to the user-provided CMake flags that this gets transformed into just `-` which ends up causing the build system to think it should read the source from stdin (which then lead to very confusing build errors). This just adds the alternative spelling before the`-stdlib=` variant in all these places Reviewed By: ldionne Differential Revision: https://reviews.llvm.org/D87133
2020-10-13 22:05:00 +08:00
remove_flags(--stdlib=libc++ -stdlib=libc++ --stdlib=libstdc++ -stdlib=libstdc++)
Reapply working parts of CMake cleanup. This patch adds the working parts of r243503. The difference with this patch is that it doesn't include the HandleLLVMOptions.cmake file. llvm-svn: 243698
2015-07-31 06:30:34 +08:00
[libc++] [CMake] Link with /nodefaultlibs on Windows 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
2017-01-14 14:06:47 +08:00
# FIXME: Remove all debug flags and flags that change which Windows
# default libraries are linked. Currently we only support linking the
# non-debug DLLs
[libc++][CMake] Use debug MSVC runtimes when libc++ is built in debug mode 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
2017-01-14 15:54:39 +08:00
remove_flags("/D_DEBUG" "/MTd" "/MDd" "/MT" "/Md")
[libc++] [CMake] Link with /nodefaultlibs on Windows 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
2017-01-14 14:06:47 +08:00
[libc++] Fix some comment typos Remove a stray letter, add a missing letter. No functional change. llvm-svn: 298766
2017-03-25 11:42:20 +08:00
# FIXME(EricWF): See the FIXME on LIBCXX_ENABLE_PEDANTIC.
Fix handling of -Wno-pedantic llvm-svn: 250452
2015-10-16 04:27:15 +08:00
# Remove the -pedantic flag and -Wno-pedantic and -pedantic-errors
[libc++] Fix some comment typos Remove a stray letter, add a missing letter. No functional change. llvm-svn: 298766
2017-03-25 11:42:20 +08:00
# so they don't get transformed into -Wno and -errors respectively.
Fix handling of -Wno-pedantic llvm-svn: 250452
2015-10-16 04:27:15 +08:00
remove_flags(-Wno-pedantic -pedantic-errors -pedantic)
Workaround -pedantic flag added by LLVM llvm-svn: 250256
2015-10-14 07:56:33 +08:00
Reapply working parts of CMake cleanup. This patch adds the working parts of r243503. The difference with this patch is that it doesn't include the HandleLLVMOptions.cmake file. llvm-svn: 243698
2015-07-31 06:30:34 +08:00
# Required flags ==============================================================
[libc++] Use functions instead of global variables to set libc++ build flags This commit follows the trend of doing things per-target instead of modifying the C++ flags globally. It does so for visibility-related flags, other basic build flags and Windows-specific flags. llvm-svn: 373517
2019-10-03 04:07:01 +08:00
function(cxx_add_basic_build_flags target)
[libc++] Require C++14 in all cases. LLVM has moved to C++14, and the libc++ build should too. C++14 is needed to provide constant initialization for certain global objects. I suspect this change may break some older GCC buildbots, and I'll clean those up as they fall.
2019-12-12 09:26:30 +08:00
[libc++] [libc++abi] Use C++20 standard. This change is needed to use char8_t when building libc++. Using the same standard in libc++abi for coherence. See https://reviews.llvm.org/D91517. Reviewed By: ldionne, #libc, #libc_abi Differential Revision: https://reviews.llvm.org/D91691
2020-11-22 22:56:39 +08:00
# Require C++20 for all targets. C++17 is needed to use aligned allocation
# in the dylib. C++20 is needed to use char8_t.
[libc++] Require C++14 in all cases. LLVM has moved to C++14, and the libc++ build should too. C++14 is needed to provide constant initialization for certain global objects. I suspect this change may break some older GCC buildbots, and I'll clean those up as they fall.
2019-12-12 09:26:30 +08:00
set_target_properties(${target} PROPERTIES
[libc++] [libc++abi] Use C++20 standard. This change is needed to use char8_t when building libc++. Using the same standard in libc++abi for coherence. See https://reviews.llvm.org/D91517. Reviewed By: ldionne, #libc, #libc_abi Differential Revision: https://reviews.llvm.org/D91691
2020-11-22 22:56:39 +08:00
CXX_STANDARD 20
CXX_STANDARD_REQUIRED NO
[libc++] Require C++14 in all cases. LLVM has moved to C++14, and the libc++ build should too. C++14 is needed to provide constant initialization for certain global objects. I suspect this change may break some older GCC buildbots, and I'll clean those up as they fall.
2019-12-12 09:26:30 +08:00
CXX_EXTENSIONS NO)
Reapply working parts of CMake cleanup. This patch adds the working parts of r243503. The difference with this patch is that it doesn't include the HandleLLVMOptions.cmake file. llvm-svn: 243698
2015-07-31 06:30:34 +08:00
[libc++] Build the dylib with -faligned-allocation This avoids issues when building the dylib for deployment targets that don't support aligned allocation, where Clang normally triggers an error to warn users their code would break at runtime when back-deployed. Since we're building the dylib itself, which contains the aligned allocation functions, we don't want to trigger that error. Differential Revision: https://reviews.llvm.org/D84418
2020-07-23 23:05:47 +08:00
# When building the dylib, don't warn for unavailable aligned allocation
# functions based on the deployment target -- they are always available
[SystemZ][ZOS] libcxx - no posix memalign The unavailability of posix_memalign on z/OS forces us to define _LIBCPP_HAS_NO_LIBRARY_ALIGNED_ALLOCATION'. The use of posix_memalign is being used in libcxx/src/new.cpp. Reviewed By: #libc, ldionne Differential Revision: https://reviews.llvm.org/D90178
2020-11-13 03:40:35 +08:00
# because they are provided by the dylib itself with the excepton of z/OS.
if (ZOS)
target_add_compile_flags_if_supported(${target} PRIVATE -fno-aligned-allocation)
else()
target_add_compile_flags_if_supported(${target} PRIVATE -faligned-allocation)
endif()
[libc++] Build the dylib with -faligned-allocation This avoids issues when building the dylib for deployment targets that don't support aligned allocation, where Clang normally triggers an error to warn users their code would break at runtime when back-deployed. Since we're building the dylib itself, which contains the aligned allocation functions, we don't want to trigger that error. Differential Revision: https://reviews.llvm.org/D84418
2020-07-23 23:05:47 +08:00
[libc++] Use functions instead of global variables to set libc++ build flags This commit follows the trend of doing things per-target instead of modifying the C++ flags globally. It does so for visibility-related flags, other basic build flags and Windows-specific flags. llvm-svn: 373517
2019-10-03 04:07:01 +08:00
# On all systems the system c++ standard library headers need to be excluded.
# MSVC only has -X, which disables all default includes; including the crt.
# Thus, we do nothing and hope we don't accidentally include any of the C++
# headers
target_add_compile_flags_if_supported(${target} PUBLIC -nostdinc++)
# Hide all inline function definitions which have not explicitly been marked
# visible. This prevents new definitions for inline functions from appearing in
# the dylib when get ODR used by another function.
target_add_compile_flags_if_supported(${target} PRIVATE -fvisibility-inlines-hidden)
# Our visibility annotations are not quite right for non-Clang compilers,
# so we end up not exporting all the symbols we should. In the future, we
# can improve the situation by providing an explicit list of exported
# symbols on all compilers.
if(CMAKE_CXX_COMPILER_ID MATCHES "Clang")
target_add_compile_flags_if_supported(${target} PRIVATE -fvisibility=hidden)
endif()
[libcxx] Build with -fvisibility-inlines-hidden -- Remove 20 inline definitions from the dylib Summary: This patch turns on `-fvisibility-inlines-hidden` when building the dylib. This is important so that libc++.dylib doesn't accidentally export inline-functions which are ODR used somewhere in the dylib. On OS X this change has no effect on the current ABI of the dylib. Unfortunately on Linux there are already ~20 inline functions which are unintentionally exported by the dylib. Almost all of these are implicitly generated destructors. I believe removing these function definitions is safe because every "linkage unit" which uses these functions has its own definition, and therefore shouldn't be dependent on libc++.dylib to provide them. Also could a FreeBSD maintainer comment on the ABI compatibility of this patch? Reviewers: mclow.lists, emaste, dexonsmith, joker-eph-DISABLED, jroelofs, danalbert, mehdi_amini, compnerd, dim Subscribers: beanz, mgorny, cfe-commits, modocache Differential Revision: https://reviews.llvm.org/D25593 llvm-svn: 285101
2016-10-26 03:43:44 +08:00
[libc++] Use functions instead of global variables to set libc++ build flags This commit follows the trend of doing things per-target instead of modifying the C++ flags globally. It does so for visibility-related flags, other basic build flags and Windows-specific flags. llvm-svn: 373517
2019-10-03 04:07:01 +08:00
if (LIBCXX_CONFIGURE_IDE)
# This simply allows IDE to process <experimental/coroutine>
target_add_compile_flags_if_supported(${target} PRIVATE -fcoroutines-ts)
endif()
Add <experimental/coroutine> This patch adds the library portions of the coroutines PDTS, which should now be supported by Clang. llvm-svn: 303836
2017-05-25 12:36:24 +08:00
[libc++] Use functions instead of global variables to set libc++ build flags This commit follows the trend of doing things per-target instead of modifying the C++ flags globally. It does so for visibility-related flags, other basic build flags and Windows-specific flags. llvm-svn: 373517
2019-10-03 04:07:01 +08:00
# Let the library headers know they are currently being used to build the
# library.
target_compile_definitions(${target} PRIVATE -D_LIBCPP_BUILDING_LIBRARY)
[libc++] Add _LIBCPP_EXTERN_TEMPLATE_INLINE_VISIBILITY to support GCC ABI compatibility Summary: GCC and Clang handle visibility attributes on the out-of-line definition of externally instantiated templates differently. For example in the reproducer below Clang will emit both 'foo' and 'bar' with default visibility while GCC only emits a non-hidden 'foo'. ``` // RUN: g++ -std=c++11 -shared -O3 test.cpp && sym_extract.py a.out // RUN: clang++ -std=c++11 -shared -O3 test.cpp && sym_extract.py a.out #define INLINE_VISIBILITY __attribute__((visibility("hidden"), always_inline)) template <class T> struct Foo { void foo(); void bar(); }; template <class T> void Foo<T>::foo() {} template <class T> inline INLINE_VISIBILITY void Foo<T>::bar() {} template struct Foo<int>; ``` This difference creates ABI incompatibilities between Clang and GCC built dylibs. Specifically GCC built dylibs lack definitions for various member functions of `basic_string`, `basic_istream`, `basic_ostream`, `basic_iostream`, and `basic_streambuf` (All of these types are externally instantiated). Surprisingly these missing symbols don't cause many problems because the functions are marked `always_inline` therefore the dylib definition is rarely needed. However when an out-of-line definition is required then GCC built dylibs will fail to link. For example [GCC built dylibs cannot build Clang](http://stackoverflow.com/questions/39454262/clang-build-errors). This patch works around this issue by adding `_LIBCPP_EXTERN_TEMPLATE_INLINE_VISIBILITY` which is used to mark externally instantiated member functions as always inline. When building the library `_LIBCPP_EXTERN_TEMPLATE_INLINE_VISIBILITY` sets the symbol's visibility to "default" instead of "hidden", otherwise it acts exactly the same as `_LIBCPP_INLINE_VISIBILITY`. After applying this patch GCC dylibs now contain: * `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE7sungetcEv` * `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE5gbumpEi` * `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE7sungetcEv` * `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE9sputbackcEc` * `_ZNSt3__113basic_istreamIwNS_11char_traitsIwEEE3getERNS_15basic_streambufIwS2_EE` * `_ZNSt3__113basic_ostreamIwNS_11char_traitsIwEEElsEPFRNS_9basic_iosIwS2_EES6_E` * `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE4setpEPcS4_` * `_ZNSt3__113basic_ostreamIwNS_11char_traitsIwEEEC1EPNS_15basic_streambufIwS2_EE` * `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE6snextcEv` * `_ZNSt3__113basic_istreamIcNS_11char_traitsIcEEE4swapERS3_` * `_ZNSt3__113basic_istreamIwNS_11char_traitsIwEEE4swapERS3_` * `_ZNSt3__112basic_stringIcNS_11char_traitsIcEENS_9allocatorIcEEE6__initEPKcm` * `_ZNSt3__113basic_istreamIcNS_11char_traitsIcEEErsEPFRNS_8ios_baseES5_E` * `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE9pubsetbufEPcl` * `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE10pubseekoffExNS_8ios_base7seekdirEj` * `_ZNSt3__113basic_istreamIwNS_11char_traitsIwEEErsEPFRNS_9basic_iosIwS2_EES6_E` * `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE5pbumpEi` * `_ZNSt3__113basic_ostreamIcNS_11char_traitsIcEEE5seekpENS_4fposI11__mbstate_tEE` * `_ZNSt3__113basic_istreamIcNS_11char_traitsIcEEE7getlineEPcl` * `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE5sgetcEv` * `_ZNSt3__113basic_istreamIcNS_11char_traitsIcEEE3getERNS_15basic_streambufIcS2_EE` * `_ZNSt3__113basic_ostreamIcNS_11char_traitsIcEEElsEPFRNS_8ios_baseES5_E` * `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE8in_availEv` * `_ZNSt3__113basic_istreamIwNS_11char_traitsIwEEErsEPFRNS_8ios_baseES5_E` * `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE6sbumpcEv` * `_ZNSt3__113basic_ostreamIcNS_11char_traitsIcEEElsEPFRNS_9basic_iosIcS2_EES6_E` * `_ZNSt3__113basic_istreamIcNS_11char_traitsIcEEE3getERc` * `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE6snextcEv` * `_ZNSt3__112basic_stringIwNS_11char_traitsIwEENS_9allocatorIwEEE6__initEmw` * `_ZNSt3__113basic_istreamIwNS_11char_traitsIwEEE7getlineEPwl` * `_ZNSt3__113basic_ostreamIcNS_11char_traitsIcEEE5tellpEv` * `_ZNSt3__113basic_istreamIwNS_11char_traitsIwEEE3getERw` * `_ZNSt3__112basic_stringIcNS_11char_traitsIcEENS_9allocatorIcEEE6__initEmc` * `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE7pubsyncEv` * `_ZNSt3__113basic_istreamIcNS_11char_traitsIcEEE3getEPcl` * `_ZNSt3__113basic_istreamIcNS_11char_traitsIcEEEC2EPNS_15basic_streambufIcS2_EE` * `_ZNSt3__113basic_istreamIcNS_11char_traitsIcEEErsEPFRNS_9basic_iosIcS2_EES6_E` * `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE7pubsyncEv` * `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE5sputcEc` * `_ZNSt3__113basic_ostreamIwNS_11char_traitsIwEEE5seekpExNS_8ios_base7seekdirE` * `_ZNKSt3__115basic_streambufIcNS_11char_traitsIcEEE6getlocEv` * `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE5gbumpEi` * `_ZNSt3__114basic_iostreamIcNS_11char_traitsIcEEE4swapERS3_` * `_ZNSt3__113basic_ostreamIwNS_11char_traitsIwEEE5seekpENS_4fposI11__mbstate_tEE` * `_ZNSt3__113basic_ostreamIwNS_11char_traitsIwEEE5tellpEv` * `_ZNSt3__113basic_ostreamIwNS_11char_traitsIwEEElsEPFRS3_S4_E` * `_ZNSt3__113basic_istreamIwNS_11char_traitsIwEEE3getEPwl` * `_ZNSt3__113basic_istreamIwNS_11char_traitsIwEEEC2EPNS_15basic_streambufIwS2_EE` * `_ZNSt3__113basic_ostreamIcNS_11char_traitsIcEEElsEPFRS3_S4_E` * `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE4setgEPcS4_S4_` * `_ZNSt3__112basic_stringIwNS_11char_traitsIwEENS_9allocatorIwEEE6__initEPKwmm` * `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE4setgEPwS4_S4_` * `_ZNSt3__113basic_istreamIwNS_11char_traitsIwEEEC1EPNS_15basic_streambufIwS2_EE` * `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE8pubimbueERKNS_6localeE` * `_ZNSt3__113basic_ostreamIcNS_11char_traitsIcEEE4swapERS3_` * `_ZNSt3__113basic_ostreamIwNS_11char_traitsIwEEEC2EPNS_15basic_streambufIwS2_EE` * `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE10pubseekposENS_4fposI11__mbstate_tEEj` * `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE5pbumpEi` * `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE5sgetcEv` * `_ZNSt3__113basic_ostreamIwNS_11char_traitsIwEEE4swapERS3_` * `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE10pubseekposENS_4fposI11__mbstate_tEEj` * `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE5sputnEPKcl` * `_ZNSt3__113basic_ostreamIcNS_11char_traitsIcEEE5seekpExNS_8ios_base7seekdirE` * `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE5sgetnEPwl` * `_ZNSt3__113basic_ostreamIwNS_11char_traitsIwEEElsEPFRNS_8ios_baseES5_E` * `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE4setpEPwS4_` * `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE5sgetnEPcl` * `_ZNKSt3__115basic_streambufIwNS_11char_traitsIwEEE6getlocEv` * `_ZNSt3__114basic_iostreamIcNS_11char_traitsIcEEEC2EPNS_15basic_streambufIcS2_EE` * `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE8pubimbueERKNS_6localeE` * `_ZNSt3__114basic_iostreamIcNS_11char_traitsIcEEEC1EPNS_15basic_streambufIcS2_EE` * `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE8in_availEv` * `_ZNSt3__113basic_istreamIcNS_11char_traitsIcEEEC1EPNS_15basic_streambufIcS2_EE` * `_ZNSt3__112basic_stringIcNS_11char_traitsIcEENS_9allocatorIcEEE6__initEPKcmm` * `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE6sbumpcEv` * `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE10pubseekoffExNS_8ios_base7seekdirEj` * `_ZNSt3__113basic_ostreamIcNS_11char_traitsIcEEEC2EPNS_15basic_streambufIcS2_EE` * `_ZNSt3__113basic_istreamIwNS_11char_traitsIwEEErsEPFRS3_S4_E` * `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE9sputbackcEw` * `_ZNSt3__112basic_stringIwNS_11char_traitsIwEENS_9allocatorIwEEE6__initEPKwm` * `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE5sputnEPKwl` * `_ZNSt3__113basic_istreamIcNS_11char_traitsIcEEErsEPFRS3_S4_E` * `_ZNSt3__113basic_ostreamIcNS_11char_traitsIcEEEC1EPNS_15basic_streambufIcS2_EE` * `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE9pubsetbufEPwl` * `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE5sputcEw` This patch has no effect on Clang based builds. Reviewers: mclow.lists, eugenis, danalbert, jroelofs, EricWF Subscribers: beanz, cfe-commits, mgorny Differential Revision: https://reviews.llvm.org/D24600 llvm-svn: 281681
2016-09-16 08:00:48 +08:00
[libc++] Use functions instead of global variables to set libc++ build flags This commit follows the trend of doing things per-target instead of modifying the C++ flags globally. It does so for visibility-related flags, other basic build flags and Windows-specific flags. llvm-svn: 373517
2019-10-03 04:07:01 +08:00
if (NOT LIBCXX_ENABLE_NEW_DELETE_DEFINITIONS)
target_compile_definitions(${target} PRIVATE -D_LIBCPP_DISABLE_NEW_DELETE_DEFINITIONS)
endif()
[libc++] Add option to disable new/delete overloads when libc++abi provides them. Summary: Currently both libc++ and libc++abi provide definitions for operator new/delete. However I believe this is incorrect and that one or the other should offer them. This patch adds the CMake option `-DLIBCXX_ENABLE_NEW_DELETE_DEFINITIONS` which defaults no `ON` unless `-DLIBCXXABI_ENABLE_NEW_DELETE_DEFINITIONS=ON` is specified. Reviewers: mclow.lists, mehdi_amini, dexonsmith, danalbert, smeenai, mgorny, rmaprath Reviewed By: mehdi_amini Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D30516 llvm-svn: 296802
2017-03-03 03:35:33 +08:00
[libc++] Use functions instead of global variables to set libc++ build flags This commit follows the trend of doing things per-target instead of modifying the C++ flags globally. It does so for visibility-related flags, other basic build flags and Windows-specific flags. llvm-svn: 373517
2019-10-03 04:07:01 +08:00
if (LIBCXX_HAS_COMMENT_LIB_PRAGMA)
[libcxx{,abi}] Emit deplibs only when detected by CMake This is a followup to 35bc5276ca3. It fixes the dependent libs usage in libcxx and libcxxabi to link pthread and rt libraries only if CMake detects them, rather than based on explicit platform blacklist. Differential Revision: https://reviews.llvm.org/D70888
2019-12-02 18:49:20 +08:00
if (LIBCXX_HAS_PTHREAD_LIB)
target_compile_definitions(${target} PRIVATE -D_LIBCPP_LINK_PTHREAD_LIB)
endif()
if (LIBCXX_HAS_RT_LIB)
target_compile_definitions(${target} PRIVATE -D_LIBCPP_LINK_RT_LIB)
endif()
[libc++] Use functions instead of global variables to set libc++ build flags This commit follows the trend of doing things per-target instead of modifying the C++ flags globally. It does so for visibility-related flags, other basic build flags and Windows-specific flags. llvm-svn: 373517
2019-10-03 04:07:01 +08:00
endif()
endfunction()
[runtimes] Check if pragma comment(lib, ...) is supported first This fixes the issue introduced by r362048 where we always use pragma comment(lib, ...) for dependent libraries when the compiler is Clang, but older Clang versions don't support this pragma so we need to check first if it's supported before using it. llvm-svn: 362055
2019-05-30 12:40:21 +08:00
Reapply working parts of CMake cleanup. This patch adds the working parts of r243503. The difference with this patch is that it doesn't include the HandleLLVMOptions.cmake file. llvm-svn: 243698
2015-07-31 06:30:34 +08:00
# Warning flags ===============================================================
[libc++] Use a function to set warning flags per target This is part of a larger shift to move to per-target settings and eradicate global variables from the CMake build. I'm starting small with warnings only because those are easy to transition over and I want to see how it pans out, but we can handle all flags like exceptions and RTTI in the future. llvm-svn: 373511
2019-10-03 03:31:30 +08:00
function(cxx_add_warning_flags target)
target_compile_definitions(${target} PUBLIC -D_LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER)
[libcxx] Don't add -Wall when building in MSVC mode The MSVC -Wall (or /Wall) option maps (in clang-cl) to the GCC style option -Weverything, which we don't really want. Instead use -W4 which is the corresponding MSVC option. This silences the build with clang-cl, which previously used to output 100 warnings per translation unit. Differential Revision: https://reviews.llvm.org/D98035
2021-03-05 20:46:30 +08:00
if (MSVC)
# -W4 is the cl.exe/clang-cl equivalent of -Wall. (In cl.exe and clang-cl,
# -Wall is equivalent to -Weverything in GCC style compiler drivers.)
target_add_compile_flags_if_supported(${target} PRIVATE -W4)
else()
target_add_compile_flags_if_supported(${target} PRIVATE -Wall)
endif()
target_add_compile_flags_if_supported(${target} PRIVATE -Wextra -W -Wwrite-strings
[libc++] Use a function to set warning flags per target This is part of a larger shift to move to per-target settings and eradicate global variables from the CMake build. I'm starting small with warnings only because those are easy to transition over and I want to see how it pans out, but we can handle all flags like exceptions and RTTI in the future. llvm-svn: 373511
2019-10-03 03:31:30 +08:00
-Wno-unused-parameter -Wno-long-long
[libc++] Build and test with -Wundef warning. NFC. This will avoid typos like `_LIBCPP_STD_VERS` (<future>) or using `#if TEST_STD_VER > 17` without including "test_macros.h". Reviewed By: ldionne, #libc Differential Revision: https://reviews.llvm.org/D99515
2021-04-01 14:29:55 +08:00
-Werror=return-type -Wextra-semi -Wundef)
[libc++] Use a function to set warning flags per target This is part of a larger shift to move to per-target settings and eradicate global variables from the CMake build. I'm starting small with warnings only because those are easy to transition over and I want to see how it pans out, but we can handle all flags like exceptions and RTTI in the future. llvm-svn: 373511
2019-10-03 03:31:30 +08:00
if ("${CMAKE_CXX_COMPILER_ID}" MATCHES "Clang")
target_add_compile_flags_if_supported(${target} PRIVATE
-Wno-user-defined-literals
-Wno-covered-switch-default
Reapply "Try enabling -Wsuggest-override again, using add_compile_options instead of add_compile_definitions for disabling it in unittests/ directories." add_compile_options is more sensitive to its location in the file than add_definitions--it only takes effect for sources that are added after it. This updated patch ensures that the add_compile_options is done before adding any source files that depend on it. Using add_definitions caused the flag to be passed to rc.exe on Windows and thus broke Windows builds.
2020-07-23 08:44:52 +08:00
-Wno-suggest-override
[libc++] Use a function to set warning flags per target This is part of a larger shift to move to per-target settings and eradicate global variables from the CMake build. I'm starting small with warnings only because those are easy to transition over and I want to see how it pans out, but we can handle all flags like exceptions and RTTI in the future. llvm-svn: 373511
2019-10-03 03:31:30 +08:00
-Wno-ignored-attributes # FIXME: Caused by _LIBCPP_NODEBUG_TYPE not being supported on older clangs
)
Turn off warnings under clang-cl llvm-svn: 343433
2018-10-01 09:15:50 +08:00
if (LIBCXX_TARGETING_CLANG_CL)
[libc++] Use a function to set warning flags per target This is part of a larger shift to move to per-target settings and eradicate global variables from the CMake build. I'm starting small with warnings only because those are easy to transition over and I want to see how it pans out, but we can handle all flags like exceptions and RTTI in the future. llvm-svn: 373511
2019-10-03 03:31:30 +08:00
target_add_compile_flags_if_supported(${target} PRIVATE
Turn off warnings under clang-cl llvm-svn: 343433
2018-10-01 09:15:50 +08:00
-Wno-c++98-compat
Remove even more warnings from clang-cl build llvm-svn: 343434
2018-10-01 09:31:23 +08:00
-Wno-c++98-compat-pedantic
Turn off warnings under clang-cl llvm-svn: 343433
2018-10-01 09:15:50 +08:00
-Wno-c++11-compat
-Wno-undef
Remove even more warnings from clang-cl build llvm-svn: 343434
2018-10-01 09:31:23 +08:00
-Wno-reserved-id-macro
-Wno-gnu-include-next
-Wno-gcc-compat # For ignoring "'diagnose_if' is a clang extension" warnings
Remove even more clang-cl warnings llvm-svn: 343436
2018-10-01 09:47:23 +08:00
-Wno-zero-as-null-pointer-constant # FIXME: Remove this and fix all occurrences.
-Wno-deprecated-dynamic-exception-spec # For auto_ptr
-Wno-sign-conversion
-Wno-old-style-cast
-Wno-deprecated # FIXME: Remove this and fix all occurrences.
Fix even more Clang warnings. This patch disables shift-sign-overflow warnings for now. It also fixes most -Wfloat-equal warnings and -Wextra-semi warnings. llvm-svn: 343438
2018-10-01 09:59:37 +08:00
-Wno-shift-sign-overflow # FIXME: Why do we need this with clang-cl but not clang?
Remove one more warning from clang-cl build llvm-svn: 343440
2018-10-01 11:59:05 +08:00
-Wno-double-promotion # FIXME: remove me
Turn off warnings under clang-cl llvm-svn: 343433
2018-10-01 09:15:50 +08:00
)
endif()
[libc++] Use a function to set warning flags per target This is part of a larger shift to move to per-target settings and eradicate global variables from the CMake build. I'm starting small with warnings only because those are easy to transition over and I want to see how it pans out, but we can handle all flags like exceptions and RTTI in the future. llvm-svn: 373511
2019-10-03 03:31:30 +08:00
elseif("${CMAKE_CXX_COMPILER_ID}" MATCHES "GNU")
target_add_compile_flags_if_supported(${target} PRIVATE
-Wno-literal-suffix
-Wno-c++14-compat
Reapply "Try enabling -Wsuggest-override again, using add_compile_options instead of add_compile_definitions for disabling it in unittests/ directories." add_compile_options is more sensitive to its location in the file than add_definitions--it only takes effect for sources that are added after it. This updated patch ensures that the add_compile_options is done before adding any source files that depend on it. Using add_definitions caused the flag to be passed to rc.exe on Windows and thus broke Windows builds.
2020-07-23 08:44:52 +08:00
-Wno-noexcept-type
-Wno-suggest-override)
[libc++] Use a function to set warning flags per target This is part of a larger shift to move to per-target settings and eradicate global variables from the CMake build. I'm starting small with warnings only because those are easy to transition over and I want to see how it pans out, but we can handle all flags like exceptions and RTTI in the future. llvm-svn: 373511
2019-10-03 03:31:30 +08:00
endif()
if (LIBCXX_ENABLE_WERROR)
target_add_compile_flags_if_supported(${target} PRIVATE -Werror)
target_add_compile_flags_if_supported(${target} PRIVATE -WX)
else()
# TODO(EricWF) Remove this. We shouldn't be suppressing errors when -Werror is
# added elsewhere.
target_add_compile_flags_if_supported(${target} PRIVATE -Wno-error)
endif()
if (LIBCXX_ENABLE_PEDANTIC)
target_add_compile_flags_if_supported(${target} PRIVATE -pedantic)
endif()
if (LIBCXX_DISABLE_MACRO_CONFLICT_WARNINGS)
target_compile_definitions(${target} PRIVATE -D_LIBCPP_DISABLE_MACRO_CONFLICT_WARNINGS)
endif()
endfunction()
Add CMake build and fix major Linux blockers. llvm-svn: 121510
2010-12-11 03:47:54 +08:00
Reapply working parts of CMake cleanup. This patch adds the working parts of r243503. The difference with this patch is that it doesn't include the HandleLLVMOptions.cmake file. llvm-svn: 243698
2015-07-31 06:30:34 +08:00
# Exception flags =============================================================
[libc++] Move more CMake flags to per-target definitions This daily refactoring tackles flags related to modules, exceptions and RTTI. llvm-svn: 373767
2019-10-05 02:03:17 +08:00
function(cxx_add_exception_flags target)
if (LIBCXX_ENABLE_EXCEPTIONS)
# Catches C++ exceptions only and tells the compiler to assume that extern C
# functions never throw a C++ exception.
target_add_compile_flags_if_supported(${target} PUBLIC -EHsc)
else()
target_add_compile_flags_if_supported(${target} PUBLIC -EHs- -EHa-)
target_add_compile_flags_if_supported(${target} PUBLIC -fno-exceptions)
endif()
endfunction()
Reapply working parts of CMake cleanup. This patch adds the working parts of r243503. The difference with this patch is that it doesn't include the HandleLLVMOptions.cmake file. llvm-svn: 243698
2015-07-31 06:30:34 +08:00
# RTTI flags ==================================================================
[libc++] Move more CMake flags to per-target definitions This daily refactoring tackles flags related to modules, exceptions and RTTI. llvm-svn: 373767
2019-10-05 02:03:17 +08:00
function(cxx_add_rtti_flags target)
if (NOT LIBCXX_ENABLE_RTTI)
target_add_compile_flags_if_supported(${target} PUBLIC -GR-)
target_add_compile_flags_if_supported(${target} PUBLIC -fno-rtti)
endif()
endfunction()
Reapply working parts of CMake cleanup. This patch adds the working parts of r243503. The difference with this patch is that it doesn't include the HandleLLVMOptions.cmake file. llvm-svn: 243698
2015-07-31 06:30:34 +08:00
[libcxx] Introduce an externally-threaded libc++ variant. This patch further decouples libc++ from pthread, allowing libc++ to be built against other threading systems. There are two main use cases: - Building libc++ against a thread library other than pthreads. - Building libc++ with an "external" thread API, allowing a separate library to provide the implementation of that API. The two use cases are quite similar, the second one being sligtly more de-coupled than the first. The cmake option LIBCXX_HAS_EXTERNAL_THREAD_API enables both kinds of builds. One needs to place an <__external_threading> header file containing an implementation of the "libc++ thread API" declared in the <__threading_support> header. For the second use case, the implementation of the libc++ thread API can delegate to a custom "external" thread API where the implementation of this external API is provided in a seperate library. This mechanism allows toolchain vendors to distribute a build of libc++ with a custom thread-porting-layer API (which is the "external" API above), platform vendors (recipients of the toolchain/libc++) are then required to provide their implementation of this API to be linked with (end-user) C++ programs. Note that the second use case still requires establishing the basic types that get passed between the external thread library and the libc++ library (e.g. __libcpp_mutex_t). These cannot be opaque pointer types (libc++ sources won't compile otherwise). It should also be noted that the second use case can have a slight performance penalty; as all the thread constructs need to cross a library boundary through an additional function call. When the header <__external_threading> is omitted, libc++ is built with the "libc++ thread API" (declared in <__threading_support>) as the "external" thread API (basic types are pthread based). An implementation (pthread based) of this API is provided in test/support/external_threads.cpp, which is built into a separate DSO and linked in when running the libc++ test suite. A test run therefore demonstrates the second use case (less the intermediate custom API). Differential revision: https://reviews.llvm.org/D21968 Reviewers: bcraig, compnerd, EricWF, mclow.lists llvm-svn: 281179
2016-09-12 05:46:40 +08:00
# Threading flags =============================================================
[libcxx] Fix externally-threaded shared library builds after r291275. Need to allow unresolved symbols in the dylib. This was previously done for LIBCXX_HAS_EXTERNAL_THREAD_API, but we have since split that into two with LIBCXX_BUILD_EXTERNAL_THREAD_LIBRARY being the externally-threaded variant. Also a minor CMakeLists.txt cleanup. llvm-svn: 291433
2017-01-09 18:38:56 +08:00
if (LIBCXX_BUILD_EXTERNAL_THREAD_LIBRARY AND LIBCXX_ENABLE_SHARED)
[libcxx] Introduce an externally-threaded libc++ variant. This patch further decouples libc++ from pthread, allowing libc++ to be built against other threading systems. There are two main use cases: - Building libc++ against a thread library other than pthreads. - Building libc++ with an "external" thread API, allowing a separate library to provide the implementation of that API. The two use cases are quite similar, the second one being sligtly more de-coupled than the first. The cmake option LIBCXX_HAS_EXTERNAL_THREAD_API enables both kinds of builds. One needs to place an <__external_threading> header file containing an implementation of the "libc++ thread API" declared in the <__threading_support> header. For the second use case, the implementation of the libc++ thread API can delegate to a custom "external" thread API where the implementation of this external API is provided in a seperate library. This mechanism allows toolchain vendors to distribute a build of libc++ with a custom thread-porting-layer API (which is the "external" API above), platform vendors (recipients of the toolchain/libc++) are then required to provide their implementation of this API to be linked with (end-user) C++ programs. Note that the second use case still requires establishing the basic types that get passed between the external thread library and the libc++ library (e.g. __libcpp_mutex_t). These cannot be opaque pointer types (libc++ sources won't compile otherwise). It should also be noted that the second use case can have a slight performance penalty; as all the thread constructs need to cross a library boundary through an additional function call. When the header <__external_threading> is omitted, libc++ is built with the "libc++ thread API" (declared in <__threading_support>) as the "external" thread API (basic types are pthread based). An implementation (pthread based) of this API is provided in test/support/external_threads.cpp, which is built into a separate DSO and linked in when running the libc++ test suite. A test run therefore demonstrates the second use case (less the intermediate custom API). Differential revision: https://reviews.llvm.org/D21968 Reviewers: bcraig, compnerd, EricWF, mclow.lists llvm-svn: 281179
2016-09-12 05:46:40 +08:00
# Need to allow unresolved symbols if this is to work with shared library builds
if (APPLE)
add_link_flags("-undefined dynamic_lookup")
else()
# Relax this restriction from HandleLLVMOptions
string(REPLACE "-Wl,-z,defs" "" CMAKE_SHARED_LINKER_FLAGS "${CMAKE_SHARED_LINKER_FLAGS}")
endif()
endif()
Reapply working parts of CMake cleanup. This patch adds the working parts of r243503. The difference with this patch is that it doesn't include the HandleLLVMOptions.cmake file. llvm-svn: 243698
2015-07-31 06:30:34 +08:00
# Assertion flags =============================================================
define_if(LIBCXX_ENABLE_ASSERTIONS -UNDEBUG)
define_if_not(LIBCXX_ENABLE_ASSERTIONS -DNDEBUG)
Recommit [libcxx] Never use <cassert> within libc++ It is my opinion that libc++ should never use `<cassert>`, including in the `dylib`. This patch remove all uses of `assert` from within libc++ and replaces most of them with `_LIBCPP_ASSERT` instead. Additionally this patch turn `LIBCXX_ENABLE_ASSERTIONS` off by default, because the standard library should not be aborting user programs unless explicitly asked to. llvm-svn: 294107
2017-02-05 07:22:28 +08:00
define_if(LIBCXX_ENABLE_ASSERTIONS -D_LIBCPP_DEBUG=0)
[libc++][CMake] Use debug MSVC runtimes when libc++ is built in debug mode 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
2017-01-14 15:54:39 +08:00
define_if(LIBCXX_DEBUG_BUILD -D_DEBUG)
if (LIBCXX_ENABLE_ASSERTIONS AND NOT LIBCXX_DEBUG_BUILD)
Add CMake build and fix major Linux blockers. llvm-svn: 121510
2010-12-11 03:47:54 +08:00
# MSVC doesn't like _DEBUG on release builds. See PR 4379.
[libc++] [CMake] Link with /nodefaultlibs on Windows 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
2017-01-14 14:06:47 +08:00
define_if_not(LIBCXX_TARGETING_MSVC -D_DEBUG)
Revert recent CMake changes again due to failing compiler-rt builds llvm-svn: 243593
2015-07-30 07:46:55 +08:00
endif()
Disable Modules when building the libc++ sources. Libc++ will not build with modules enabled. In order to support an in-tree libc++ when LLVM_ENABLE_MODULES is ON we need to explicitly disable the feature. Unfortunately the libc++ sources are fundamentally non-modular. For example iostream.cpp defines cout, cerr, wout, ... as char buffers instead of streams in order to better control initialization/destruction. Not shockingly Clang diagnoses this. Many other sources files define _LIBCPP_BUILDING_FOO macros to provide definitions for normally inline symbols (See bind.cpp). Finally The current module.map prohibits using <strstream> in C++11 so we can't build strstream.cpp. I think I can fix most of these issues but until then just disable modules. llvm-svn: 284230
2016-10-14 20:56:52 +08:00
# Modules flags ===============================================================
# FIXME The libc++ sources are fundamentally non-modular. They need special
# versions of the headers in order to provide C++03 and legacy ABI definitions.
# NOTE: The public headers can be used with modules in all other contexts.
[libc++] Move more CMake flags to per-target definitions This daily refactoring tackles flags related to modules, exceptions and RTTI. llvm-svn: 373767
2019-10-05 02:03:17 +08:00
function(cxx_add_module_flags target)
if (LLVM_ENABLE_MODULES)
# Ignore that the rest of the modules flags are now unused.
[libc++] Make the modules-related flags PUBLIC instead of PRIVATE It appears that those need to be propagated to targets that use libc++ as well, otherwise they don't build properly. llvm-svn: 373773
2019-10-05 03:10:56 +08:00
target_add_compile_flags_if_supported(${target} PUBLIC -Wno-unused-command-line-argument)
target_compile_options(${target} PUBLIC -fno-modules)
[libc++] Move more CMake flags to per-target definitions This daily refactoring tackles flags related to modules, exceptions and RTTI. llvm-svn: 373767
2019-10-05 02:03:17 +08:00
endif()
endfunction()
Disable Modules when building the libc++ sources. Libc++ will not build with modules enabled. In order to support an in-tree libc++ when LLVM_ENABLE_MODULES is ON we need to explicitly disable the feature. Unfortunately the libc++ sources are fundamentally non-modular. For example iostream.cpp defines cout, cerr, wout, ... as char buffers instead of streams in order to better control initialization/destruction. Not shockingly Clang diagnoses this. Many other sources files define _LIBCPP_BUILDING_FOO macros to provide definitions for normally inline symbols (See bind.cpp). Finally The current module.map prohibits using <strstream> in C++11 so we can't build strstream.cpp. I think I can fix most of these issues but until then just disable modules. llvm-svn: 284230
2016-10-14 20:56:52 +08:00
Misc drive-by cleanups. NFC http://reviews.llvm.org/D12294 llvm-svn: 245876
2015-08-25 05:20:07 +08:00
# Sanitizer flags =============================================================
Add CMake build and fix major Linux blockers. llvm-svn: 121510
2010-12-11 03:47:54 +08:00
Add cxx-benchmark-unittests target This patch adds the cxx-benchmark-unittests target so we can start getting test coverage on the benchmarks, including building with sanitizers. Because we're only looking for test-coverage, the benchmarks run for the shortest time possible, and in parallel. The target is excluded from all by default. It only builds and runs the libcxx configurations of the benchmarks, and not any versions built against the systems native standard library. llvm-svn: 346811
2018-11-14 07:08:31 +08:00
function(get_sanitizer_flags OUT_VAR USE_SANITIZER)
set(SANITIZER_FLAGS)
set(USE_SANITIZER "${USE_SANITIZER}")
Revert recent CMake changes again due to failing compiler-rt builds llvm-svn: 243593
2015-07-30 07:46:55 +08:00
# NOTE: LLVM_USE_SANITIZER checks for a UNIX like system instead of MSVC.
# But we don't have LLVM_ON_UNIX so checking for MSVC is the best we can do.
Add cxx-benchmark-unittests target This patch adds the cxx-benchmark-unittests target so we can start getting test coverage on the benchmarks, including building with sanitizers. Because we're only looking for test-coverage, the benchmarks run for the shortest time possible, and in parallel. The target is excluded from all by default. It only builds and runs the libcxx configurations of the benchmarks, and not any versions built against the systems native standard library. llvm-svn: 346811
2018-11-14 07:08:31 +08:00
if (USE_SANITIZER AND NOT MSVC)
append_flags_if_supported(SANITIZER_FLAGS "-fno-omit-frame-pointer")
append_flags_if_supported(SANITIZER_FLAGS "-gline-tables-only")
Reapply working parts of CMake cleanup. This patch adds the working parts of r243503. The difference with this patch is that it doesn't include the HandleLLVMOptions.cmake file. llvm-svn: 243698
2015-07-31 06:30:34 +08:00
Revert recent CMake changes again due to failing compiler-rt builds llvm-svn: 243593
2015-07-30 07:46:55 +08:00
if (NOT uppercase_CMAKE_BUILD_TYPE STREQUAL "DEBUG" AND
Add cxx-benchmark-unittests target This patch adds the cxx-benchmark-unittests target so we can start getting test coverage on the benchmarks, including building with sanitizers. Because we're only looking for test-coverage, the benchmarks run for the shortest time possible, and in parallel. The target is excluded from all by default. It only builds and runs the libcxx configurations of the benchmarks, and not any versions built against the systems native standard library. llvm-svn: 346811
2018-11-14 07:08:31 +08:00
NOT uppercase_CMAKE_BUILD_TYPE STREQUAL "RELWITHDEBINFO")
append_flags_if_supported(SANITIZER_FLAGS "-gline-tables-only")
Revert recent CMake changes again due to failing compiler-rt builds llvm-svn: 243593
2015-07-30 07:46:55 +08:00
endif()
Add cxx-benchmark-unittests target This patch adds the cxx-benchmark-unittests target so we can start getting test coverage on the benchmarks, including building with sanitizers. Because we're only looking for test-coverage, the benchmarks run for the shortest time possible, and in parallel. The target is excluded from all by default. It only builds and runs the libcxx configurations of the benchmarks, and not any versions built against the systems native standard library. llvm-svn: 346811
2018-11-14 07:08:31 +08:00
if (USE_SANITIZER STREQUAL "Address")
append_flags(SANITIZER_FLAGS "-fsanitize=address")
elseif (USE_SANITIZER MATCHES "Memory(WithOrigins)?")
append_flags(SANITIZER_FLAGS -fsanitize=memory)
if (USE_SANITIZER STREQUAL "MemoryWithOrigins")
append_flags(SANITIZER_FLAGS "-fsanitize-memory-track-origins")
Revert recent CMake changes again due to failing compiler-rt builds llvm-svn: 243593
2015-07-30 07:46:55 +08:00
endif()
Add cxx-benchmark-unittests target This patch adds the cxx-benchmark-unittests target so we can start getting test coverage on the benchmarks, including building with sanitizers. Because we're only looking for test-coverage, the benchmarks run for the shortest time possible, and in parallel. The target is excluded from all by default. It only builds and runs the libcxx configurations of the benchmarks, and not any versions built against the systems native standard library. llvm-svn: 346811
2018-11-14 07:08:31 +08:00
elseif (USE_SANITIZER STREQUAL "Undefined")
append_flags(SANITIZER_FLAGS "-fsanitize=undefined -fno-sanitize=vptr,function -fno-sanitize-recover=all")
libcxx 'LLVM_USE_SANITIZER=Address;Undefined' Summary: Allow users to simultaneously enable address and undefined behavior sanitizers, in the same manner that LLVM's 'HandleLLVMOptions.cmake' allows. Prior to this patch, `cmake -DLLVM_USE_SANITIZER="Address;Undefined"` would succeed and the build would build most of the LLVM project with `-fsanitize=address,undefined`, but a warning would be printed by libcxx's CMake, and the build would use neither sanitizer. This patch results in no warning being printed, and both sanitizers are used in building libcxx. Reviewers: jroelofs, EricWF, ldionne, #libc! Subscribers: mgorny, dexonsmith, llvm-commits, libcxx-commits Tags: #libc Differential Revision: https://reviews.llvm.org/D77466
2020-04-05 01:01:32 +08:00
elseif (USE_SANITIZER STREQUAL "Address;Undefined" OR
USE_SANITIZER STREQUAL "Undefined;Address")
append_flags(SANITIZER_FLAGS "-fsanitize=address,undefined -fno-sanitize=vptr,function -fno-sanitize-recover=all")
Add cxx-benchmark-unittests target This patch adds the cxx-benchmark-unittests target so we can start getting test coverage on the benchmarks, including building with sanitizers. Because we're only looking for test-coverage, the benchmarks run for the shortest time possible, and in parallel. The target is excluded from all by default. It only builds and runs the libcxx configurations of the benchmarks, and not any versions built against the systems native standard library. llvm-svn: 346811
2018-11-14 07:08:31 +08:00
elseif (USE_SANITIZER STREQUAL "Thread")
append_flags(SANITIZER_FLAGS -fsanitize=thread)
[dfsan] Add "DataFlow" option to LLVM_USE_SANITIZER Summary: This patch add the dataflow option to LLVM_USE_SANITIZER and documents it. Tested via check-cxx (wip to fix the errors). Reviewers: morehouse, #libc! Subscribers: mgorny, cfe-commits, libcxx-commits Tags: #clang, #libc Differential Revision: https://reviews.llvm.org/D78390
2020-04-18 01:15:58 +08:00
elseif (USE_SANITIZER STREQUAL "DataFlow")
append_flags(SANITIZER_FLAGS -fsanitize=dataflow)
Revert recent CMake changes again due to failing compiler-rt builds llvm-svn: 243593
2015-07-30 07:46:55 +08:00
else()
Add cxx-benchmark-unittests target This patch adds the cxx-benchmark-unittests target so we can start getting test coverage on the benchmarks, including building with sanitizers. Because we're only looking for test-coverage, the benchmarks run for the shortest time possible, and in parallel. The target is excluded from all by default. It only builds and runs the libcxx configurations of the benchmarks, and not any versions built against the systems native standard library. llvm-svn: 346811
2018-11-14 07:08:31 +08:00
message(WARNING "Unsupported value of LLVM_USE_SANITIZER: ${USE_SANITIZER}")
Revert recent CMake changes again due to failing compiler-rt builds llvm-svn: 243593
2015-07-30 07:46:55 +08:00
endif()
Add cxx-benchmark-unittests target This patch adds the cxx-benchmark-unittests target so we can start getting test coverage on the benchmarks, including building with sanitizers. Because we're only looking for test-coverage, the benchmarks run for the shortest time possible, and in parallel. The target is excluded from all by default. It only builds and runs the libcxx configurations of the benchmarks, and not any versions built against the systems native standard library. llvm-svn: 346811
2018-11-14 07:08:31 +08:00
elseif(USE_SANITIZER AND MSVC)
Reapply working parts of CMake cleanup. This patch adds the working parts of r243503. The difference with this patch is that it doesn't include the HandleLLVMOptions.cmake file. llvm-svn: 243698
2015-07-31 06:30:34 +08:00
message(WARNING "LLVM_USE_SANITIZER is not supported on this platform.")
Revert recent CMake changes again due to failing compiler-rt builds llvm-svn: 243593
2015-07-30 07:46:55 +08:00
endif()
Add cxx-benchmark-unittests target This patch adds the cxx-benchmark-unittests target so we can start getting test coverage on the benchmarks, including building with sanitizers. Because we're only looking for test-coverage, the benchmarks run for the shortest time possible, and in parallel. The target is excluded from all by default. It only builds and runs the libcxx configurations of the benchmarks, and not any versions built against the systems native standard library. llvm-svn: 346811
2018-11-14 07:08:31 +08:00
set(${OUT_VAR} "${SANITIZER_FLAGS}" PARENT_SCOPE)
endfunction()
# Configure for sanitizers. If LIBCXX_STANDALONE_BUILD then we have to do
# the flag translation ourselves. Othewise LLVM's CMakeList.txt will handle it.
if (LIBCXX_STANDALONE_BUILD)
set(LLVM_USE_SANITIZER "" CACHE STRING
"Define the sanitizer used to build the library and tests")
endif()
get_sanitizer_flags(SANITIZER_FLAGS "${LLVM_USE_SANITIZER}")
if (LIBCXX_STANDALONE_BUILD AND SANITIZER_FLAGS)
add_flags(${SANITIZER_FLAGS})
Revert recent CMake changes again due to failing compiler-rt builds llvm-svn: 243593
2015-07-30 07:46:55 +08:00
endif()
[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++] Make sure we link all system libraries into the benchmarks It turns out that r374056 broke _some_ build bots again, specifically the ones using sanitizers. Instead of trying to link the right system libraries to the benchmarks bit-by-bit, let's just link exactly the system libraries that libc++ itself needs. llvm-svn: 374079
2019-10-09 00:26:24 +08:00
# Link system libraries =======================================================
function(cxx_link_system_libraries target)
[SystemZ][ZOS] Prefer -nostdlib++ as opposed to -nodefaultlibs when building c++ libraries Let's use -nostdlib++ rather than -nodefaultlibs when building libc++/libc++abi/libunwind libraries. The default is -nostdlib++ if supported by a build compiler like it is the case with clang, otherwise -nodefaultlibs is used as before. This change is needed to avoid additional changes at the link step and not to increase the maintenance costs. If clang with -nodefaultlibs is used all the libraries which are removed but required would have to be manually added in. This set of libraries are unique and will send out. The propose change will allow to make the link step simple for other platforms as well. Reviewed By: #libc, #libc_abi, ldionne Differential Revision: https://reviews.llvm.org/D95875
2021-02-17 02:02:22 +08:00
# In order to remove just libc++ from the link step
# we need to use -nostdlib++ whenever it is supported.
# Unfortunately this cannot be used universally because for example g++ supports
# only -nodefaultlibs in which case all libraries will be removed and
# all libraries but c++ have to be added in manually.
if (LIBCXX_SUPPORTS_NOSTDLIBXX_FLAG)
target_add_link_flags_if_supported(${target} PRIVATE "-nostdlib++")
else()
target_add_link_flags_if_supported(${target} PRIVATE "-nodefaultlibs")
target_add_compile_flags_if_supported(${target} PRIVATE "/Zl")
target_add_link_flags_if_supported(${target} PRIVATE "/nodefaultlib")
endif()
[libc++] Make sure we link all system libraries into the benchmarks It turns out that r374056 broke _some_ build bots again, specifically the ones using sanitizers. Instead of trying to link the right system libraries to the benchmarks bit-by-bit, let's just link exactly the system libraries that libc++ itself needs. llvm-svn: 374079
2019-10-09 00:26:24 +08:00
if (LIBCXX_HAS_SYSTEM_LIB)
target_link_libraries(${target} PRIVATE System)
endif()
if (LIBCXX_HAS_PTHREAD_LIB)
target_link_libraries(${target} PRIVATE pthread)
endif()
if (LIBCXX_HAS_C_LIB)
target_link_libraries(${target} PRIVATE c)
endif()
if (LIBCXX_HAS_M_LIB)
target_link_libraries(${target} PRIVATE m)
endif()
if (LIBCXX_HAS_RT_LIB)
target_link_libraries(${target} PRIVATE rt)
endif()
if (LIBCXX_USE_COMPILER_RT)
find_compiler_rt_library(builtins LIBCXX_BUILTINS_LIBRARY)
if (LIBCXX_BUILTINS_LIBRARY)
target_link_libraries(${target} PRIVATE "${LIBCXX_BUILTINS_LIBRARY}")
endif()
[libcxx][libcxxabi][libunwind] Use libgcc on Android Android doesn't have a libgcc_s and uses libgcc instead, so adjust the build accordingly. This matches compiler-rt's build setup. libc++abi and libunwind were already checking for libgcc but in a different context. This change makes them search only for libgcc on Android now, but the code to link against libgcc if it were present was already there. Reviewed By: #libc, #libc_abi, #libunwind, rprichard, srhines Differential Revision: https://reviews.llvm.org/D78787
2020-04-24 12:19:11 +08:00
elseif (LIBCXX_HAS_GCC_LIB)
target_link_libraries(${target} PRIVATE gcc)
[libc++] Make sure we link all system libraries into the benchmarks It turns out that r374056 broke _some_ build bots again, specifically the ones using sanitizers. Instead of trying to link the right system libraries to the benchmarks bit-by-bit, let's just link exactly the system libraries that libc++ itself needs. llvm-svn: 374079
2019-10-09 00:26:24 +08:00
elseif (LIBCXX_HAS_GCC_S_LIB)
target_link_libraries(${target} PRIVATE gcc_s)
endif()
[libc++] Link against libatomic when it is found Before this patch, we tried detecting whether small atomics were available without linking against libatomic. However, that's not really what we want to know -- instead, we want to know what's required in order to support atomics fully, which is to link against libatomic when it's provided. That is both much simpler, and it doesn't suffer the problem that we would not link against libatomic when small atomics didn't require it, which lead to non-lockfree atomics never working. Furthermore, because we understand that some platforms might not want to (or be able to) ship non-lockfree atomics, we add that notion to the test suite, independently of a potential extern library. After this patch, we therefore: (1) Link against libatomic when it is provided (2) Independently detect whether non-lockfree atomics are supported in the test suite, regardless of whether that means we're linking against an external library or not (which is an implementation detail). Differential Revision: https://reviews.llvm.org/D81190
2020-06-05 02:54:38 +08:00
if (LIBCXX_HAS_ATOMIC_LIB)
[libc++] Make sure we link all system libraries into the benchmarks It turns out that r374056 broke _some_ build bots again, specifically the ones using sanitizers. Instead of trying to link the right system libraries to the benchmarks bit-by-bit, let's just link exactly the system libraries that libc++ itself needs. llvm-svn: 374079
2019-10-09 00:26:24 +08:00
target_link_libraries(${target} PRIVATE atomic)
endif()
if (MINGW)
target_link_libraries(${target} PRIVATE "${MINGW_LIBRARIES}")
endif()
if (LIBCXX_TARGETING_MSVC)
if (LIBCXX_DEBUG_BUILD)
set(LIB_SUFFIX "d")
else()
set(LIB_SUFFIX "")
endif()
target_link_libraries(${target} PRIVATE ucrt${LIB_SUFFIX}) # Universal C runtime
target_link_libraries(${target} PRIVATE vcruntime${LIB_SUFFIX}) # C++ runtime
target_link_libraries(${target} PRIVATE msvcrt${LIB_SUFFIX}) # C runtime startup files
target_link_libraries(${target} PRIVATE msvcprt${LIB_SUFFIX}) # C++ standard library. Required for exception_ptr internals.
# Required for standards-complaint wide character formatting functions
# (e.g. `printfw`/`scanfw`)
target_link_libraries(${target} PRIVATE iso_stdio_wide_specifiers)
endif()
[libcxx] Link against android_support when needed libc++ on Android needs to be linked against libandroid_support on API levels less than 21 to provide needed functions that aren't in the libc on those platforms (e.g. posix_memalign for libcxxabi). libc++ from the NDK is a linker script that pulls in libandroid_support, but for building libc++ itself, we need to explicitly add libandroid_support as a dependency. Moreover, libc++ headers reference the functions provided by libandroid_support, so it needs to be added as a public dependency. Differential Revision: https://reviews.llvm.org/D73516
2020-01-28 09:29:41 +08:00
if (ANDROID AND ANDROID_PLATFORM_LEVEL LESS 21)
target_link_libraries(${target} PUBLIC android_support)
endif()
[libc++] Make sure we link all system libraries into the benchmarks It turns out that r374056 broke _some_ build bots again, specifically the ones using sanitizers. Instead of trying to link the right system libraries to the benchmarks bit-by-bit, let's just link exactly the system libraries that libc++ itself needs. llvm-svn: 374079
2019-10-09 00:26:24 +08:00
endfunction()
[libc++] Use functions instead of global variables to set libc++ build flags This commit follows the trend of doing things per-target instead of modifying the C++ flags globally. It does so for visibility-related flags, other basic build flags and Windows-specific flags. llvm-svn: 373517
2019-10-03 04:07:01 +08:00
# Windows-related flags =======================================================
function(cxx_add_windows_flags target)
if(WIN32 AND NOT MINGW)
target_compile_definitions(${target} PRIVATE
# Ignore the -MSC_VER mismatch, as we may build
# with a different compatibility version.
_ALLOW_MSC_VER_MISMATCH
# Don't check the msvcprt iterator debug levels
# as we will define the iterator types; libc++
# uses a different macro to identify the debug
# level.
_ALLOW_ITERATOR_DEBUG_LEVEL_MISMATCH
# We are building the c++ runtime, don't pull in
# msvcprt.
_CRTBLD
# Don't warn on the use of "deprecated"
# "insecure" functions which are standards
# specified.
_CRT_SECURE_NO_WARNINGS
# Use the ISO conforming behaviour for conversion
# in printf, scanf.
_CRT_STDIO_ISO_WIDE_SPECIFIERS)
endif()
endfunction()
[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
# Configuration file flags =====================================================
[libc++] Remove Fuchsia-specific knowledge to pick the ABI version Summary: The ABI version used by libc++ is a configuration option just like any other configuration option. It is a knob that can be used by vendors to customize the libc++ that they ship. As such, we should not be hardcoding vendor-specific configuration choices in libc++. When building libc++ for Fuchsia, Fuchsia's build scripts should simply define the libc++ ABI version to 2 -- this will result in the _LIBCPP_ABI_VERSION macro being defined in the __config header that is generated when libc++ is built and installed, which is the correct way to customize libc++'s behavior for specific vendors. Reviewers: phosek, EricWF Subscribers: mgorny, christof, dexonsmith, cfe-commits, libcxx-commits Differential Revision: https://reviews.llvm.org/D52397 llvm-svn: 343079
2018-09-26 16:24:51 +08:00
if (NOT LIBCXX_ABI_VERSION EQUAL 1)
ABI versioning macros for libc++. C++ macros and CMake options that specify the default ABI version of the library, and can be overridden to pick up new ABI-changing features. llvm-svn: 250254
2015-10-14 07:48:28 +08:00
config_define(${LIBCXX_ABI_VERSION} _LIBCPP_ABI_VERSION)
endif()
Make libc++'s versioning namespace customizable Summary: This patch makes the versioning namespace libc++ uses customizable by the user using `-DLIBCXX_ABI_NAMESPACE=__foo`. This allows users to build custom versions of libc++ which can be linked into binaries with other libc++ versions without causing symbol conflicts or ODR issues. Reviewers: mclow.lists, ldionne Reviewed By: ldionne Subscribers: kristina, smeenai, mgorny, phosek, libcxx-commits Differential Revision: https://reviews.llvm.org/D53879 llvm-svn: 345657
2018-10-31 05:44:53 +08:00
if (NOT LIBCXX_ABI_NAMESPACE STREQUAL "")
if (NOT LIBCXX_ABI_NAMESPACE MATCHES "__.*")
[libc++] Force the ABI namespace to be a reserved identifier Summary: When the ABI namespace isn't a reserved identifier, we were issuing a warning, but this should have been an error since the beginning. This commit enforces that the ABI namespace is a reserved identifier, and changes the ABI namespace used by LibFuzzer. Reviewers: phosek, EricWF Subscribers: mgorny, christof, jkorous, dexonsmith, #sanitizers, libcxx-commits, llvm-commits Tags: #sanitizers, #libc, #llvm Differential Revision: https://reviews.llvm.org/D69408
2019-10-25 05:16:37 +08:00
message(FATAL_ERROR "LIBCXX_ABI_NAMESPACE must be a reserved identifier.")
Make libc++'s versioning namespace customizable Summary: This patch makes the versioning namespace libc++ uses customizable by the user using `-DLIBCXX_ABI_NAMESPACE=__foo`. This allows users to build custom versions of libc++ which can be linked into binaries with other libc++ versions without causing symbol conflicts or ODR issues. Reviewers: mclow.lists, ldionne Reviewed By: ldionne Subscribers: kristina, smeenai, mgorny, phosek, libcxx-commits Differential Revision: https://reviews.llvm.org/D53879 llvm-svn: 345657
2018-10-31 05:44:53 +08:00
endif()
if (LIBCXX_ABI_NAMESPACE MATCHES "__[0-9]+$")
message(FATAL_ERROR "LIBCXX_ABI_NAMESPACE '${LIBCXX_ABI_NAMESPACE}' is reserved for use by libc++.")
endif()
config_define(${LIBCXX_ABI_NAMESPACE} _LIBCPP_ABI_NAMESPACE)
endif()
ABI versioning macros for libc++. C++ macros and CMake options that specify the default ABI version of the library, and can be overridden to pick up new ABI-changing features. llvm-svn: 250254
2015-10-14 07:48:28 +08:00
config_define_if(LIBCXX_ABI_UNSTABLE _LIBCPP_ABI_UNSTABLE)
[libc++] Clarify names of ABI forcing macros Make it clear that these are intended only to force a specific ABI when the autodetection would give the wrong result by renaming the cmake options and adding separate forcing macros, as suggested by EricWF in the post-commit review of r314949 and further discussed on IRC. llvm-svn: 314965
2017-10-05 10:18:08 +08:00
config_define_if(LIBCXX_ABI_FORCE_ITANIUM _LIBCPP_ABI_FORCE_ITANIUM)
config_define_if(LIBCXX_ABI_FORCE_MICROSOFT _LIBCPP_ABI_FORCE_MICROSOFT)
[libcxx] By default, do not use internal_linkage to hide symbols from the ABI Summary: https://reviews.llvm.org/D49240 led to symbol size problems in Chromium, and we expect this may be the case in other projects built in debug mode too. Instead, unless users explicitly ask for internal_linkage, we use always_inline like we used to. In the future, when we have a solution that allows us to drop always_inline without falling back on internal_linkage, we can replace always_inline by that. Note that this commit introduces a change in contract for existing libc++ users: by default, libc++ used to guarantee that TUs built with different versions of libc++ could be linked together. With the introduction of the _LIBCPP_HIDE_FROM_ABI_PER_TU macro, the default behavior is that TUs built with different libc++ versions are not guaranteed to link. This is a change in contract but not a change in behavior, since the current implementation still allows linking TUs built with different libc++ versions together. Reviewers: EricWF, mclow.lists, dexonsmith, hans, rnk Subscribers: christof, cfe-commits Differential Revision: https://reviews.llvm.org/D50652 llvm-svn: 339874
2018-08-16 20:44:28 +08:00
config_define_if(LIBCXX_HIDE_FROM_ABI_PER_TU_BY_DEFAULT _LIBCPP_HIDE_FROM_ABI_PER_TU_BY_DEFAULT)
[libcxx] Capture configuration information when installing the libc++ headers Summary: Hi all, This patch is a successor to D11963. However it has changed dramatically and I felt it would be best to start a new review thread. Please read the design documentation added in this patch for a description of how it works. Reviewers: mclow.lists, danalbert, jroelofs, EricWF Subscribers: vkalintiris, rnk, ed, espositofulvio, asl, eugenis, cfe-commits Differential Revision: http://reviews.llvm.org/D13407 llvm-svn: 250235
2015-10-14 06:12:02 +08:00
config_define_if_not(LIBCXX_ENABLE_GLOBAL_FILESYSTEM_NAMESPACE _LIBCPP_HAS_NO_GLOBAL_FILESYSTEM_NAMESPACE)
config_define_if_not(LIBCXX_ENABLE_STDIN _LIBCPP_HAS_NO_STDIN)
config_define_if_not(LIBCXX_ENABLE_STDOUT _LIBCPP_HAS_NO_STDOUT)
config_define_if_not(LIBCXX_ENABLE_THREADS _LIBCPP_HAS_NO_THREADS)
config_define_if_not(LIBCXX_ENABLE_MONOTONIC_CLOCK _LIBCPP_HAS_NO_MONOTONIC_CLOCK)
config_define_if_not(LIBCXX_ENABLE_THREAD_UNSAFE_C_FUNCTIONS _LIBCPP_HAS_NO_THREAD_UNSAFE_C_FUNCTIONS)
[libc++] Clarify how we pick the typeinfo comparison This commit makes it clear that the typeinfo comparison implementation is automatically selected by default, and that the CMake option only overrides the value. This has been a source of confusion and bugs ever since we've introduced complexity in that area, so I'm trying to simplify it while still allowing for some control on the implementation. Differential Revision: https://reviews.llvm.org/D91574
2020-11-17 07:13:43 +08:00
if (NOT LIBCXX_TYPEINFO_COMPARISON_IMPLEMENTATION STREQUAL "default")
[libc++] Fix the LIBCXX_HAS_MERGED_TYPEINFO_NAMES_DEFAULT setting When the __config_site header is generated, but LIBCXX_HAS_MERGED_TYPEINFO_NAMES_DEFAULT wasn't specified, _LIBCPP_HAS_MERGED_TYPEINFO_NAMES_DEFAULT would be defined to 0, which was the NonUnique RTTI comparison implementation. The intent was to use the Unique RTTI comparison implementation in that case, which caused https://llvm.org/PR45549. Instead, use a proper "switch" to select the RTTI comparison implementation. Note that 0 can't be used as a value, because that is treated the same by CMake as a variable that is just not defined. Differential Revision: https://reviews.llvm.org/D80037
2020-05-16 03:58:19 +08:00
config_define("${LIBCXX_TYPEINFO_COMPARISON_IMPLEMENTATION}" _LIBCPP_TYPEINFO_COMPARISON_IMPLEMENTATION)
Rework std::type_info definition to support systems without fully merged type info names. Previously std::type_info always expected type info string to be unique. But this isn't always the case. Like when -Bsymbolic is passed to the linker or due to llvm.org/PR37398. This patch adds the LIBCXX_HAS_MERGED_TYPEINFO_NAMES_DEFAULT CMake option which, when specified, overrides the default configuration for the library. The current defaults still assume unique names even though this isn't strictly correct for ELF binaries. We should consider changing the default in a follow up commit. llvm-svn: 361913
2019-05-29 10:21:37 +08:00
endif()
[libcxx] Allow explicit pthread opt-in The existing pthread detection code in __config is pretty good for common operating systems. It doesn't allow cmake-time choices to be made for uncommon operating systems though. This change adds the LIBCXX_HAS_PTHREAD_API cmake flag, which turns into the _LIBCPP_HAS_THREAD_API_PTHREAD preprocessor define. This is a name change from the old _LIBCPP_THREAD_API_PTHREAD. The lit tests want __config_site.in variables to have a _LIBCPP_HAS prefix. http://reviews.llvm.org/D20573 llvm-svn: 270735
2016-05-26 01:40:09 +08:00
config_define_if(LIBCXX_HAS_PTHREAD_API _LIBCPP_HAS_THREAD_API_PTHREAD)
[libcxx] Introduce an externally-threaded libc++ variant. This patch further decouples libc++ from pthread, allowing libc++ to be built against other threading systems. There are two main use cases: - Building libc++ against a thread library other than pthreads. - Building libc++ with an "external" thread API, allowing a separate library to provide the implementation of that API. The two use cases are quite similar, the second one being sligtly more de-coupled than the first. The cmake option LIBCXX_HAS_EXTERNAL_THREAD_API enables both kinds of builds. One needs to place an <__external_threading> header file containing an implementation of the "libc++ thread API" declared in the <__threading_support> header. For the second use case, the implementation of the libc++ thread API can delegate to a custom "external" thread API where the implementation of this external API is provided in a seperate library. This mechanism allows toolchain vendors to distribute a build of libc++ with a custom thread-porting-layer API (which is the "external" API above), platform vendors (recipients of the toolchain/libc++) are then required to provide their implementation of this API to be linked with (end-user) C++ programs. Note that the second use case still requires establishing the basic types that get passed between the external thread library and the libc++ library (e.g. __libcpp_mutex_t). These cannot be opaque pointer types (libc++ sources won't compile otherwise). It should also be noted that the second use case can have a slight performance penalty; as all the thread constructs need to cross a library boundary through an additional function call. When the header <__external_threading> is omitted, libc++ is built with the "libc++ thread API" (declared in <__threading_support>) as the "external" thread API (basic types are pthread based). An implementation (pthread based) of this API is provided in test/support/external_threads.cpp, which is built into a separate DSO and linked in when running the libc++ test suite. A test run therefore demonstrates the second use case (less the intermediate custom API). Differential revision: https://reviews.llvm.org/D21968 Reviewers: bcraig, compnerd, EricWF, mclow.lists llvm-svn: 281179
2016-09-12 05:46:40 +08:00
config_define_if(LIBCXX_HAS_EXTERNAL_THREAD_API _LIBCPP_HAS_THREAD_API_EXTERNAL)
[cmake] Add a config option LIBCXX_HAS_WIN32_THREAD_API for enforcing win32 threads This allows keeping libcxx using win32 threads even if a version of pthread.h is installed. This matches the existing cmake option LIBCXX_HAS_PTHREAD_API. Also add missing documentation about the internal define _LIBCPP_HAS_THREAD_API_WIN32. Differential Revision: https://reviews.llvm.org/D41764 llvm-svn: 321896
2018-01-06 04:48:29 +08:00
config_define_if(LIBCXX_HAS_WIN32_THREAD_API _LIBCPP_HAS_THREAD_API_WIN32)
[libc++] Cleanup and document <__threading_support> Summary: This patch attempts to clean up the macro configuration mess in `<__threading_support>`, specifically the mess involving external threading variants. Additionally this patch adds design documentation for `<__threading_support>` and the configuration macros it uses. The primary change in this patch is separating the idea of an "external API" provided by `<__external_threading>` and the idea of having an external threading library. Now `_LIBCPP_HAS_THREAD_API_EXTERNAL` means that libc++ should use `<__external_threading>` and that the header is expected to exist. Additionally the new macro `_LIBCPP_HAS_THREAD_LIBRARY_EXTERNAL` is now used to configure for using an "external library" with the default threading API. Reviewers: compnerd, rmaprath Subscribers: smeenai, cfe-commits, mgorny Differential Revision: https://reviews.llvm.org/D28316 llvm-svn: 291275
2017-01-07 04:05:40 +08:00
config_define_if(LIBCXX_BUILD_EXTERNAL_THREAD_LIBRARY _LIBCPP_HAS_THREAD_LIBRARY_EXTERNAL)
Add initial support for the MUSL C library. Summary: This patch adds the LIBCXX_LIBC_IS_MUSL cmake option to allow the building of libcxx with the Musl C library. The option is necessary as Musl does not provide any predefined macro in order to test for its presence, like GLIBC. Most of the changes specify the correct path to choose through the various #if/#else constructs in the locale code. Depends on D13407. Reviewers: mclow.lists, jroelofs, EricWF Subscribers: jfb, tberghammer, danalbert, srhines, cfe-commits Differential Revision: http://reviews.llvm.org/D13673 llvm-svn: 252457
2015-11-09 18:21:04 +08:00
config_define_if(LIBCXX_HAS_MUSL_LIBC _LIBCPP_HAS_MUSL_LIBC)
[libc++] Support Microsoft ABI without vcruntime headers The vcruntime headers are hairy and clash with both libc++ headers themselves and other libraries. libc++ normally deals with the clashes by deferring to the vcruntime headers and silencing its own definitions, but for clients which don't want to depend on vcruntime headers, it's desirable to support the opposite, i.e. have libc++ provide its own definitions. Certain operator new/delete replacement scenarios are not currently supported in this mode, which requires some tests to be marked XFAIL. The added documentation has more details. Differential Revision: https://reviews.llvm.org/D38522 llvm-svn: 315234
2017-10-10 03:25:17 +08:00
config_define_if(LIBCXX_NO_VCRUNTIME _LIBCPP_NO_VCRUNTIME)
[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
config_define_if(LIBCXX_ENABLE_PARALLEL_ALGORITHMS _LIBCPP_HAS_PARALLEL_ALGORITHMS)
[libc++] Make LIBCXX_ENABLE_FILESYSTEM fully consistent Previously, LIBCXX_ENABLE_FILESYSTEM controlled only whether the filesystem support was compiled into libc++'s library. This commit promotes the setting to a first-class option like LIBCXX_ENABLE_LOCALIZATION, where the whole library is aware of the setting and features that depend on <filesystem> won't be provided at all. The test suite is also properly annotated such that tests that depend on <filesystem> are disabled when the library doesn't support it. This is an alternative to https://llvm.org/D94824, but also an improvement along the lines of LIBCXX_ENABLE_LOCALIZATION that I had been wanting to make for a while. Differential Revision: https://reviews.llvm.org/D94921
2021-01-19 01:18:18 +08:00
config_define_if_not(LIBCXX_ENABLE_FILESYSTEM _LIBCPP_HAS_NO_FILESYSTEM_LIBRARY)
[libc++] Allow building libc++ on platforms without a random device Some platforms, like several embedded platforms, do not provide a source of randomness through a random device. This commit makes it possible to build and test libc++ for such platforms, i.e. without std::random_device. Surprisingly, the only functionality that doesn't work on such platforms is std::random_device itself -- everything else in <random> still works, one just has to find alternative ways to seed the PRNGs.
2020-10-15 22:32:09 +08:00
config_define_if_not(LIBCXX_ENABLE_RANDOM_DEVICE _LIBCPP_HAS_NO_RANDOM_DEVICE)
[libc++] Add a libc++ configuration that does not support localization When porting libc++ to embedded systems, it can be useful to drop support for localization, which these systems don't implement or care about. Differential Revision: https://reviews.llvm.org/D90072
2020-10-10 03:31:05 +08:00
config_define_if_not(LIBCXX_ENABLE_LOCALIZATION _LIBCPP_HAS_NO_LOCALIZATION)
[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
config_define_if_not(LIBCXX_ENABLE_VENDOR_AVAILABILITY_ANNOTATIONS _LIBCPP_HAS_NO_VENDOR_AVAILABILITY_ANNOTATIONS)
Add initial support for the MUSL C library. Summary: This patch adds the LIBCXX_LIBC_IS_MUSL cmake option to allow the building of libcxx with the Musl C library. The option is necessary as Musl does not provide any predefined macro in order to test for its presence, like GLIBC. Most of the changes specify the correct path to choose through the various #if/#else constructs in the locale code. Depends on D13407. Reviewers: mclow.lists, jroelofs, EricWF Subscribers: jfb, tberghammer, danalbert, srhines, cfe-commits Differential Revision: http://reviews.llvm.org/D13673 llvm-svn: 252457
2015-11-09 18:21:04 +08:00
[libc++] Add site config option for ABI macros Some ABI macros affect headers, so it's nice to have a site config option for them. Add a LIBCXX_ABI_DEFINES cmake macro to allow specifying a list of ABI macros to define in the site config. The primary design constraint (as discussed with Eric on IRC a while back) was to not have to repeat the ABI macro names in cmake, which only leaves a free-form cmake list as an option. A somewhat unfortunate consequence is that we can't verify that the ABI macros being defined actually exist, though we can at least perform some basic sanity checking, since all the ABI macros begin with _LIBCPP_ABI_. Differential Revision: https://reviews.llvm.org/D36719 llvm-svn: 314946
2017-10-05 07:17:12 +08:00
if (LIBCXX_ABI_DEFINES)
set(abi_defines)
foreach (abi_define ${LIBCXX_ABI_DEFINES})
if (NOT abi_define MATCHES "^_LIBCPP_ABI_")
message(SEND_ERROR "Invalid ABI macro ${abi_define} in LIBCXX_ABI_DEFINES")
endif()
list(APPEND abi_defines "#define ${abi_define}")
endforeach()
string(REPLACE ";" "\n" abi_defines "${abi_defines}")
config_define(${abi_defines} _LIBCPP_ABI_DEFINES)
endif()
Expect DLL builds on Windows by default and require a custom __config for static builds. On Windows the __declspec(dllimport) and __declspec(dllexport) attributes require linking to a DLL, not a static library. Previously these annotations were disabled by default unless _LIBCPP_DLL was defined. However the DLL configuration is probably the more common one, so it should be supported by default. This patch enables import/export attributes by default and adds a _LIBCPP_DISABLE_DLL_IMPORT_EXPORT macro which can be used to disable this behavior. If libc++ is built as a static library on Windows then a custom __config header will be generated that predefines this macro. This patch is based off work by Shoaib Meenai. llvm-svn: 282449
2016-09-27 06:19:41 +08:00
# By default libc++ on Windows expects to use a shared library, which requires
# the headers to use DLL import/export semantics. However when building a
# static library only we modify the headers to disable DLL import/export.
if (DEFINED WIN32 AND LIBCXX_ENABLE_STATIC AND NOT LIBCXX_ENABLE_SHARED)
message(STATUS "Generating custom __config for non-DLL Windows build")
[libc++] Add _LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS It's useful to be able to disable visibility annotations entirely; for example, if we're building libc++ static to include in another library, and we don't want any libc++ functions getting exported out of that library. This is a generalization of _LIBCPP_DISABLE_DLL_IMPORT_EXPORT. Differential Revision: https://reviews.llvm.org/D26934 llvm-svn: 288690
2016-12-06 03:40:12 +08:00
config_define(ON _LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS)
Expect DLL builds on Windows by default and require a custom __config for static builds. On Windows the __declspec(dllimport) and __declspec(dllexport) attributes require linking to a DLL, not a static library. Previously these annotations were disabled by default unless _LIBCPP_DLL was defined. However the DLL configuration is probably the more common one, so it should be supported by default. This patch enables import/export attributes by default and adds a _LIBCPP_DISABLE_DLL_IMPORT_EXPORT macro which can be used to disable this behavior. If libc++ is built as a static library on Windows then a custom __config header will be generated that predefines this macro. This patch is based off work by Shoaib Meenai. llvm-svn: 282449
2016-09-27 06:19:41 +08:00
endif()
[libcxx] [libcxxabi] Set flags for visibility when statically linking libcxxabi into libcxx for windows Previously, these had to be set manually when building each of the projects standalone, in order to get proper symbol visibility when combining the two libraries. Differential Revision: https://reviews.llvm.org/D90021
2020-10-23 15:54:02 +08:00
if (WIN32 AND LIBCXX_ENABLE_STATIC_ABI_LIBRARY)
# If linking libcxxabi statically into libcxx, skip the dllimport attributes
# on symbols we refer to from libcxxabi.
add_definitions(-D_LIBCXXABI_DISABLE_VISIBILITY_ANNOTATIONS)
endif()
[libc++] Localize common build flags into a single CMake function Also, set those flags for the cxx_experimental target. Otherwise, cxx_experimental doesn't build properly when neither the static nor the shared library is compiled (yes, that is a weird setup). llvm-svn: 373808
2019-10-05 06:50:23 +08:00
# Setup all common build flags =================================================
function(cxx_add_common_build_flags target)
cxx_add_basic_build_flags(${target})
cxx_add_warning_flags(${target})
cxx_add_windows_flags(${target})
cxx_add_exception_flags(${target})
cxx_add_rtti_flags(${target})
cxx_add_module_flags(${target})
[libc++] Make sure we link all system libraries into the benchmarks It turns out that r374056 broke _some_ build bots again, specifically the ones using sanitizers. Instead of trying to link the right system libraries to the benchmarks bit-by-bit, let's just link exactly the system libraries that libc++ itself needs. llvm-svn: 374079
2019-10-09 00:26:24 +08:00
cxx_link_system_libraries(${target})
[libc++] Localize common build flags into a single CMake function Also, set those flags for the cxx_experimental target. Otherwise, cxx_experimental doesn't build properly when neither the static nor the shared library is compiled (yes, that is a weird setup). llvm-svn: 373808
2019-10-05 06:50:23 +08:00
endfunction()
Add CMake build and fix major Linux blockers. llvm-svn: 121510
2010-12-11 03:47:54 +08:00
#===============================================================================
Reapply working parts of CMake cleanup. This patch adds the working parts of r243503. The difference with this patch is that it doesn't include the HandleLLVMOptions.cmake file. llvm-svn: 243698
2015-07-31 06:30:34 +08:00
# Setup Source Code And Tests
Add CMake build and fix major Linux blockers. llvm-svn: 121510
2010-12-11 03:47:54 +08:00
#===============================================================================
Justin Bogner: This makes the headers available in the build directory, making it easier to use freshly-built clang with freshly-built libc++. Basically, this 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/ llvm-svn: 194825
2013-11-16 01:18:57 +08:00
add_subdirectory(include)
[libcxx] Move CMake file to src, avoid using globs This addresses the longstanding FIXME and makes libc++ build more similar to other runtimes. Differential Revision: https://reviews.llvm.org/D61275 llvm-svn: 359656
2019-05-01 14:40:36 +08:00
add_subdirectory(src)
[libcxx] Add new Sphinx documentation Summary: This patch adds Sphinx based documentation to libc++. The goal is to make it easier to write documentation for libc++ since writing new documentation in HTML is cumbersome. This patch rewrites the main page for libc++ along with the instructions for using, building and testing libc++. The built documentation can be found and reviewed here: http://efcs.ca/libcxx-docs In order to build the sphinx documentation you need to specify the cmake options `-DLLVM_ENABLE_SPHINX=ON -DLIBCXX_INCLUDE_DOCS=ON`. This will add the makefile rule `docs-libcxx-html`. Reviewers: chandlerc, mclow.lists, danalbert, jroelofs Subscribers: silvas, cfe-commits Differential Revision: http://reviews.llvm.org/D12129 llvm-svn: 245788
2015-08-23 03:40:49 +08:00
Rename cxx-benchmark-unittests target and convert to LIT. This patch renames the cxx-benchmark-unittests to check-cxx-benchmarks and converts the target to use LIT in order to make the tests run faster and provide better output. In particular this runs each benchmark in a suite one by one, allowing more parallelism while ensuring output isn't garbage with multiple threads. Additionally, it adds the CMake flag '-DLIBCXX_BENCHMARK_TEST_ARGS=<list>' to specify what options are passed when running the benchmarks. llvm-svn: 346888
2018-11-15 04:38:46 +08:00
set(LIBCXX_TEST_DEPS "")
if (LIBCXX_ENABLE_EXPERIMENTAL_LIBRARY)
list(APPEND LIBCXX_TEST_DEPS cxx_experimental)
endif()
if (LIBCXX_BUILD_EXTERNAL_THREAD_LIBRARY)
list(APPEND LIBCXX_TEST_DEPS cxx_external_threads)
endif()
Add check-cxx-abilist target when supported. This patch adds a `check-cxx-abilist` target which verifies the libc++.so ABI when the current build configuration matches the configuration used to generate the ABI lists. In order to make this change `HandleOutOfTreeLLVM.cmake` needed to be modified to include `LLVMConfig.cmake` so that `TARGET_TRIPLE` is defined. Hopefully the changes needed to accommodate this won't break existing build configurations. llvm-svn: 286789
2016-11-14 10:43:12 +08:00
[libcxx] Add support for benchmark tests using Google Benchmark. Summary: This patch does the following: 1. Checks in a copy of the Google Benchmark library into the libc++ repo under `utils/google-benchmark`. 2. Teaches libc++ how to build Google Benchmark against both (A) in-tree libc++ and (B) the platforms native STL. 3. Allows performance benchmarks to be built as part of the libc++ build. Building the benchmarks (and Google Benchmark) is off by default. It must be enabled using the CMake option `-DLIBCXX_INCLUDE_BENCHMARKS=ON`. When this option is enabled the tests under `libcxx/benchmarks` can be built using the `libcxx-benchmarks` target. On Linux platforms where libstdc++ is the default STL the CMake option `-DLIBCXX_BUILD_BENCHMARKS_NATIVE_STDLIB=ON` can be used to build each benchmark test against libstdc++ as well. This is useful for comparing performance between standard libraries. Support for benchmarks is currently very minimal. They must be manually run by the user and there is no mechanism for detecting performance regressions. Known Issues: * `-DLIBCXX_INCLUDE_BENCHMARKS=ON` is only supported for Clang, and not GCC, since the `-stdlib=libc++` option is needed to build Google Benchmark. Reviewers: danalbert, dberlin, chandlerc, mclow.lists, jroelofs Subscribers: chandlerc, dberlin, tberghammer, danalbert, srhines, hfinkel Differential Revision: https://reviews.llvm.org/D22240 llvm-svn: 276049
2016-07-20 07:07:03 +08:00
if (LIBCXX_INCLUDE_BENCHMARKS)
add_subdirectory(benchmarks)
endif()
Generate the test configuration even when LIBCXX_INCLUDE_TESTS=OFF. This patch changes the CMake configuration so that it always generates the test/lit.site.cfg file, even when testing is disabled. This allows users to test libc++ without requiring them to have a full LLVM checkout on their machine. llvm-svn: 296685
2017-03-02 05:53:30 +08:00
Reapply working parts of CMake cleanup. This patch adds the working parts of r243503. The difference with this patch is that it doesn't include the HandleLLVMOptions.cmake file. llvm-svn: 243698
2015-07-31 06:30:34 +08:00
if (LIBCXX_INCLUDE_TESTS)
[libc++] Do not try creating llvm-lit when LIBCXX_INCLUDE_TESTS is OFF in the standalone build Doing so doesn't work reliably, since it relies on LLVM_* implementation detail variables being set. Furthermore, since we rely on the lit.site.cfg being generated, running the tests requires LIBCXX_INCLUDE_TESTS=ON anyway.
2020-06-29 23:51:15 +08:00
add_subdirectory(test)
Add check-cxx-abilist target when supported. This patch adds a `check-cxx-abilist` target which verifies the libc++.so ABI when the current build configuration matches the configuration used to generate the ABI lists. In order to make this change `HandleOutOfTreeLLVM.cmake` needed to be modified to include `LLVMConfig.cmake` so that `TARGET_TRIPLE` is defined. Hopefully the changes needed to accommodate this won't break existing build configurations. llvm-svn: 286789
2016-11-14 10:43:12 +08:00
add_subdirectory(lib/abi)
[libc++] Do not try creating llvm-lit when LIBCXX_INCLUDE_TESTS is OFF in the standalone build Doing so doesn't work reliably, since it relies on LLVM_* implementation detail variables being set. Furthermore, since we rely on the lit.site.cfg being generated, running the tests requires LIBCXX_INCLUDE_TESTS=ON anyway.
2020-06-29 23:51:15 +08:00
if (LIBCXX_STANDALONE_BUILD)
include(AddLLVM) # for get_llvm_lit_path
# Make sure the llvm-lit script is generated into the bin directory, and
# do it after adding all tests, since the generated script will only work
# correctly discovered tests against test locations from the source tree
# that have already been discovered.
add_subdirectory(${LLVM_MAIN_SRC_DIR}/utils/llvm-lit
${CMAKE_CURRENT_BINARY_DIR}/llvm-lit)
endif()
Resubmit "Fix llvm-lit script generation in libcxx." After speaking with the libcxx owners, they agreed that this is a bug in the bot that needs to be fixed by the bot owners, and the CMake changes are correct. llvm-svn: 313643
2017-09-20 01:19:10 +08:00
endif()
[libcxx] Add new Sphinx documentation Summary: This patch adds Sphinx based documentation to libc++. The goal is to make it easier to write documentation for libc++ since writing new documentation in HTML is cumbersome. This patch rewrites the main page for libc++ along with the instructions for using, building and testing libc++. The built documentation can be found and reviewed here: http://efcs.ca/libcxx-docs In order to build the sphinx documentation you need to specify the cmake options `-DLLVM_ENABLE_SPHINX=ON -DLIBCXX_INCLUDE_DOCS=ON`. This will add the makefile rule `docs-libcxx-html`. Reviewers: chandlerc, mclow.lists, danalbert, jroelofs Subscribers: silvas, cfe-commits Differential Revision: http://reviews.llvm.org/D12129 llvm-svn: 245788
2015-08-23 03:40:49 +08:00
if (LIBCXX_INCLUDE_DOCS)
add_subdirectory(docs)
endif()