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

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

427 lines
15 KiB
CMake
Raw Normal View History

[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
set(LIBCXX_LIB_CMAKEFILES_DIR "${CMAKE_CURRENT_BINARY_DIR}${CMAKE_FILES_DIRECTORY}" PARENT_SCOPE)
Add CMake build and fix major Linux blockers. llvm-svn: 121510
2010-12-11 03:47:54 +08:00
# Get sources
[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
set(LIBCXX_SOURCES
algorithm.cpp
any.cpp
[libc++] Implementation of C++20's P1135R6 for libcxx Differential Revision: https://reviews.llvm.org/D68480
2020-02-18 22:58:34 +08:00
atomic.cpp
barrier.cpp
[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
bind.cpp
charconv.cpp
chrono.cpp
condition_variable.cpp
Make ~mutex and ~condition_variable trivial on Windows. The implementations of __libcpp_mutex_destroy and __libcpp_condvar_destroy are already NOPs, so this optimization is safe to perform. See r365273 and PR27658 for more information. llvm-svn: 365281
2019-07-08 01:24:03 +08:00
condition_variable_destructor.cpp
[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
exception.cpp
[libc++] Implement format_error. This is the first step at implementing <format>. It adds the <format> header and implements the `format_error`. class. Implemnts parts of: -P0645 Text Formatting Reviewed By: ldionne, #libc, miscco, curdeius Differential Revision: https://reviews.llvm.org/D92214
2020-11-27 02:12:18 +08:00
format.cpp
[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
functional.cpp
future.cpp
hash.cpp
include/apple_availability.h
include/atomic_support.h
include/config_elast.h
include/refstring.h
memory.cpp
mutex.cpp
Fix PR27658 - Make ~mutex trivial when possible. Currently std::mutex has a constexpr constructor, but a non-trivial destruction. The constexpr constructor is required to ensure the construction of a mutex with static storage duration happens at compile time, during constant initialization, and not during dynamic initialization. This means that static mutex's are always initialized and can be used safely during dynamic initialization without the "static initialization order fiasco". A trivial destructor is important for similar reasons. If a mutex is used during dynamic initialization it might also be used during program termination. If a static mutex has a non-trivial destructor it will be invoked during termination. This can introduce the "static deinitialization order fiasco". Additionally, function-local statics emit a guard variable around non-trivially destructible types. This results in horrible codegen and adds a runtime cost to every call to that function. non-local static's also result in slightly worse codegen but it's not as big of a problem. Example codegen can be found here: https://goo.gl/3CSzbM Note: This optimization is not safe with every pthread implementation. Some implementations allocate on the first call to pthread_mutex_lock and free the allocation in pthread_mutex_destroy. Also, changing the triviality of the destructor is not an ABI break. At least to the best of my knowledge :-) llvm-svn: 365273
2019-07-07 09:20:54 +08:00
mutex_destructor.cpp
[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
new.cpp
optional.cpp
[libc++] Split dylib instantiations for deprecated std::random_shuffle into a separate source file That makes it easier to exclude from the build if one wants to build libc++ without support for the deprecated std::random_shuffle.
2020-07-01 00:42:44 +08:00
random_shuffle.cpp
[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
shared_mutex.cpp
stdexcept.cpp
string.cpp
support/runtime/exception_fallback.ipp
support/runtime/exception_glibcxx.ipp
support/runtime/exception_libcxxabi.ipp
support/runtime/exception_libcxxrt.ipp
support/runtime/exception_msvc.ipp
support/runtime/exception_pointer_cxxabi.ipp
support/runtime/exception_pointer_glibcxx.ipp
support/runtime/exception_pointer_msvc.ipp
support/runtime/exception_pointer_unimplemented.ipp
support/runtime/new_handler_fallback.ipp
support/runtime/stdexcept_default.ipp
support/runtime/stdexcept_vcruntime.ipp
system_error.cpp
thread.cpp
typeinfo.cpp
utility.cpp
valarray.cpp
variant.cpp
vector.cpp
)
[libc++] Rename LIBCXX_ENABLE_DEBUG_MODE to LIBCXX_ENABLE_DEBUG_MODE_SUPPORT To make it clearer this is about whether the library supports the debug mode at all, not whether the debug mode is enabled. Per comment by Nico Weber on IRC.
2020-10-10 02:39:20 +08:00
if (LIBCXX_ENABLE_DEBUG_MODE_SUPPORT)
[gn build] (manually) port ce1365f8f7e
2020-10-07 22:33:40 +08:00
list(APPEND LIBCXX_SOURCES
debug.cpp
)
[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
endif()
[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
if (LIBCXX_ENABLE_RANDOM_DEVICE)
list(APPEND LIBCXX_SOURCES
random.cpp
)
endif()
[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
if (LIBCXX_ENABLE_LOCALIZATION)
list(APPEND LIBCXX_SOURCES
ios.cpp
[libc++] Split off iostreams explicit instantiations into its own source file This makes it cleaner to add more instantiations without cluttering the actual implementation of ios.
2020-11-02 23:30:29 +08:00
ios.instantiations.cpp
[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
iostream.cpp
locale.cpp
regex.cpp
strstream.cpp
)
endif()
Partial Windows port by Ruben Van Boxem llvm-svn: 140328
2011-09-23 03:10:18 +08:00
if(WIN32)
[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
list(APPEND LIBCXX_SOURCES
support/win32/locale_win32.cpp
support/win32/support.cpp
)
[libc++] Build thread_win32.cpp only if LIBCXX_HAS_PTHREAD_API is not set This allows building libc++ against winpthreads from mingw-w64 to support operating systems older than Windows 7. The remaining libc++ code already supports `WIN32` with `LIBCXX_HAS_PTHREAD_API`. Note that there is also the older "pthreads-win32". However, that support library implements `pthread_t` as a struct, which violates the libc++ assumption that `pthread_t` is always a scalar and can be compared, ordered, and set to zero. Differential Revision: https://reviews.llvm.org/D96339
2021-02-16 23:03:04 +08:00
if (NOT LIBCXX_HAS_PTHREAD_API)
list(APPEND LIBCXX_SOURCES
support/win32/thread_win32.cpp
)
endif()
Fixes to get libc++ building on sun solaris. Patch from C Bergstrom. llvm-svn: 222794
2014-11-26 05:57:41 +08:00
elseif("${CMAKE_SYSTEM_NAME}" STREQUAL "SunOS")
[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
list(APPEND LIBCXX_SOURCES
support/solaris/mbsnrtowcs.inc
support/solaris/wcsnrtombs.inc
support/solaris/xlocale.cpp
)
[SystemZ][z/OS] Missing locale functions libc++ The aim is to add the missing z/OS specific locale functions for libc++ (newlocale, freelocale and uselocale). Reviewed By: ldionne, #libc, curdeius Differential Revision: https://reviews.llvm.org/D98044
2021-03-09 03:20:22 +08:00
elseif(ZOS)
list(APPEND LIBCXX_SOURCES
support/ibm/xlocale_zos.cpp
)
Partial Windows port by Ruben Van Boxem llvm-svn: 140328
2011-09-23 03:10:18 +08:00
endif()
Add CMake build and fix major Linux blockers. llvm-svn: 121510
2010-12-11 03:47:54 +08:00
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
if (LIBCXX_ENABLE_FILESYSTEM)
[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
list(APPEND LIBCXX_SOURCES
filesystem/filesystem_common.h
filesystem/operations.cpp
filesystem/directory_iterator.cpp
[libcxx] Implement the stat function family on top of native windows APIs While the windows CRTs (the modern UCRT, and the legacy msvcrt.dll that mingw still often defaults to) do provide stat functions, they're a bit lacking - they only provide second precision on the modification time, lack support for symlinks and a few other details. Instead reimplement them using a couple windows native functions, getting exactly the info we need. (Technically, the implementation within the CRT calls these functions anyway.) If we only need a few fields, we could also do with fewer calls, as a later optimization. Differential Revision: https://reviews.llvm.org/D91141
2020-11-04 22:59:07 +08:00
filesystem/posix_compat.h
[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
)
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
# Filesystem uses __int128_t, which requires a definition of __muloi4 when
# compiled with UBSAN. This definition is not provided by libgcc_s, but is
# provided by compiler-rt. So we need to disable it to avoid having multiple
# definitions. See filesystem/int128_builtins.cpp.
if (NOT LIBCXX_USE_COMPILER_RT)
[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
list(APPEND LIBCXX_SOURCES
filesystem/int128_builtins.cpp
)
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
endif()
[libc++] Build <filesystem> support as part of the dylib Summary: This patch treats <filesystem> as a first-class citizen of the dylib, like all other sub-libraries (e.g. <chrono>). As such, it also removes all special handling for installing the filesystem library separately or disabling part of the test suite from the lit command line. Unlike the previous attempt (r356500), this doesn't remove all the filesystem tests. Reviewers: mclow.lists, EricWF, serge-sans-paille Subscribers: mgorny, christof, jkorous, dexonsmith, jfb, jdoerfert, libcxx-commits Differential Revision: https://reviews.llvm.org/D59152 llvm-svn: 356518
2019-03-20 04:56:13 +08:00
endif()
Add CMake build and fix major Linux blockers. llvm-svn: 121510
2010-12-11 03:47:54 +08:00
# Add all the headers to the project for IDEs.
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
if (LIBCXX_CONFIGURE_IDE)
Allow libc++ to be built with CMake from within the LLVM tree. The libc++ part is just some renaming as the variable was already in use, conflicting with something else in the LLVM tree. Contributed by Ruben Van Boxem. llvm-svn: 153036
2012-03-19 23:40:23 +08:00
file(GLOB_RECURSE LIBCXX_HEADERS ${CMAKE_CURRENT_SOURCE_DIR}/../include/*)
Partial Windows port by Ruben Van Boxem llvm-svn: 140328
2011-09-23 03:10:18 +08:00
if(WIN32)
[libc++] Rename include/support to include/__support We do ship those headers, so the directory name should not be something that can potentially conflict with user-defined directories. Differential Revision: https://reviews.llvm.org/D95956
2021-02-03 05:58:38 +08:00
file( GLOB LIBCXX_WIN32_HEADERS ${CMAKE_CURRENT_SOURCE_DIR}/../include/__support/win32/*.h)
Allow libc++ to be built with CMake from within the LLVM tree. The libc++ part is just some renaming as the variable was already in use, conflicting with something else in the LLVM tree. Contributed by Ruben Van Boxem. llvm-svn: 153036
2012-03-19 23:40:23 +08:00
list(APPEND LIBCXX_HEADERS ${LIBCXX_WIN32_HEADERS})
Partial Windows port by Ruben Van Boxem llvm-svn: 140328
2011-09-23 03:10:18 +08:00
endif()
Add CMake build and fix major Linux blockers. llvm-svn: 121510
2010-12-11 03:47:54 +08:00
# Force them all into the headers dir on MSVC, otherwise they end up at
# project scope because they don't have extensions.
if (MSVC_IDE)
Allow libc++ to be built with CMake from within the LLVM tree. The libc++ part is just some renaming as the variable was already in use, conflicting with something else in the LLVM tree. Contributed by Ruben Van Boxem. llvm-svn: 153036
2012-03-19 23:40:23 +08:00
source_group("Header Files" FILES ${LIBCXX_HEADERS})
Add CMake build and fix major Linux blockers. llvm-svn: 121510
2010-12-11 03:47:54 +08:00
endif()
endif()
[CMake] If you're not installing the libcxx library, exclude it from the "all" target so it doesn't get built when you run "ninja install" This is just a build dependency optimization. Running check-libcxx will still build libcxx and function as expected, it just removes libcxx from the all build and install targets. llvm-svn: 254628
2015-12-04 02:52:54 +08:00
if(NOT LIBCXX_INSTALL_LIBRARY)
set(exclude_from_all EXCLUDE_FROM_ALL)
endif()
build: use more portable spelling for flag Use `CMAKE_LIBRARY_PATH_FLAG` instead of hard-coding it to -L. This silences a warning with cl which expects `/LIBPATH` instead. llvm-svn: 290938
2017-01-04 13:49:55 +08:00
# If LIBCXX_CXX_ABI_LIBRARY_PATH is defined we want to add it to the search path.
add_link_flags_if(LIBCXX_CXX_ABI_LIBRARY_PATH
"${CMAKE_LIBRARY_PATH_FLAG}${LIBCXX_CXX_ABI_LIBRARY_PATH}")
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
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
if (LIBCXX_GENERATE_COVERAGE AND NOT LIBCXX_COVERAGE_LIBRARY)
find_compiler_rt_library(profile LIBCXX_COVERAGE_LIBRARY)
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
add_library_flags_if(LIBCXX_COVERAGE_LIBRARY "${LIBCXX_COVERAGE_LIBRARY}")
[libcxx] Add support for sanitizers on OS X. Summary: This patch adds special configuration logic to find the compiler_rt libraries required by sanitizers on OS X. The supported sanitizers are Address and Undefined. Reviewers: mclow.lists Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D11381 llvm-svn: 242858
2015-07-22 08:33:36 +08:00
if (APPLE AND LLVM_USE_SANITIZER)
[libcxx] Allow sanitizing libcxx with ASan+UBSan simultaneously Allow building with LLVM_USE_SANITIZER=“Address;Undefined” (and “Undefined;Address”). Differential Revision: https://reviews.llvm.org/D24569 llvm-svn: 281603
2016-09-15 19:04:53 +08:00
if (("${LLVM_USE_SANITIZER}" STREQUAL "Address") OR
("${LLVM_USE_SANITIZER}" STREQUAL "Address;Undefined") OR
("${LLVM_USE_SANITIZER}" STREQUAL "Undefined;Address"))
[libcxx] Add support for sanitizers on OS X. Summary: This patch adds special configuration logic to find the compiler_rt libraries required by sanitizers on OS X. The supported sanitizers are Address and Undefined. Reviewers: mclow.lists Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D11381 llvm-svn: 242858
2015-07-22 08:33:36 +08:00
set(LIBFILE "libclang_rt.asan_osx_dynamic.dylib")
elseif("${LLVM_USE_SANITIZER}" STREQUAL "Undefined")
set(LIBFILE "libclang_rt.ubsan_osx_dynamic.dylib")
[libcxx] Enable building and testing of libcxx with ThreadSanitizer on OS X This patch enables building and testing libcxx under ThreadSanitizer on OS X. CMake builds that have -DLLVM_USE_SANITIZER=Thread will automatically build libcxx with -fsanitize=thread and testing via lit then runs under TSan. Differential Revision: https://reviews.llvm.org/D24297 llvm-svn: 281475
2016-09-14 22:12:50 +08:00
elseif("${LLVM_USE_SANITIZER}" STREQUAL "Thread")
set(LIBFILE "libclang_rt.tsan_osx_dynamic.dylib")
[libcxx] Add support for sanitizers on OS X. Summary: This patch adds special configuration logic to find the compiler_rt libraries required by sanitizers on OS X. The supported sanitizers are Address and Undefined. Reviewers: mclow.lists Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D11381 llvm-svn: 242858
2015-07-22 08:33:36 +08:00
else()
message(WARNING "LLVM_USE_SANITIZER=${LLVM_USE_SANITIZER} is not supported on OS X")
endif()
if (LIBFILE)
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
find_compiler_rt_dir(LIBDIR)
[libcxx] Add support for sanitizers on OS X. Summary: This patch adds special configuration logic to find the compiler_rt libraries required by sanitizers on OS X. The supported sanitizers are Address and Undefined. Reviewers: mclow.lists Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D11381 llvm-svn: 242858
2015-07-22 08:33:36 +08:00
if (NOT IS_DIRECTORY "${LIBDIR}")
message(FATAL_ERROR "Cannot find compiler-rt directory on OS X required for LLVM_USE_SANITIZER")
endif()
set(LIBCXX_SANITIZER_LIBRARY "${LIBDIR}/${LIBFILE}")
set(LIBCXX_SANITIZER_LIBRARY "${LIBCXX_SANITIZER_LIBRARY}" PARENT_SCOPE)
message(STATUS "Manually linking compiler-rt library: ${LIBCXX_SANITIZER_LIBRARY}")
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_library_flags("${LIBCXX_SANITIZER_LIBRARY}")
add_link_flags("-Wl,-rpath,${LIBDIR}")
[libcxx] Add support for sanitizers on OS X. Summary: This patch adds special configuration logic to find the compiler_rt libraries required by sanitizers on OS X. The supported sanitizers are Address and Undefined. Reviewers: mclow.lists Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D11381 llvm-svn: 242858
2015-07-22 08:33:36 +08:00
endif()
endif()
[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
if (LIBCXX_ENABLE_PARALLEL_ALGORITHMS AND NOT TARGET pstl::ParallelSTL)
message(FATAL_ERROR "Could not find ParallelSTL")
endif()
[libc++] Do not share an object library to create the static/shared libraries Summary: The problem with using an object library for doing this is that it prevents the shared library and the static library from being built with the right default flags. For example, CMake will build shared libraries with -fPIC by default, but not static libraries. Using an object library to create the shared library will prevent the right default flags for shared libraries from being used. As a side effect, this patch also localizes the logic related to building a hermetic static library to the static library case, making clear that this has no effect on the shared library. Reviewers: phosek, EricWF Subscribers: mgorny, christof, jkorous, dexonsmith, jdoerfert, libcxx-commits Differential Revision: https://reviews.llvm.org/D59248 llvm-svn: 356150
2019-03-14 22:19:08 +08:00
function(cxx_set_common_defines name)
[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
if(LIBCXX_CXX_ABI_HEADER_TARGET)
add_dependencies(${name} ${LIBCXX_CXX_ABI_HEADER_TARGET})
endif()
[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
if (LIBCXX_ENABLE_PARALLEL_ALGORITHMS)
target_link_libraries(${name} PUBLIC pstl::ParallelSTL)
endif()
[libc++] Do not share an object library to create the static/shared libraries Summary: The problem with using an object library for doing this is that it prevents the shared library and the static library from being built with the right default flags. For example, CMake will build shared libraries with -fPIC by default, but not static libraries. Using an object library to create the shared library will prevent the right default flags for shared libraries from being used. As a side effect, this patch also localizes the logic related to building a hermetic static library to the static library case, making clear that this has no effect on the shared library. Reviewers: phosek, EricWF Subscribers: mgorny, christof, jkorous, dexonsmith, jdoerfert, libcxx-commits Differential Revision: https://reviews.llvm.org/D59248 llvm-svn: 356150
2019-03-14 22:19:08 +08:00
endfunction()
[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
[libc++] Do not share an object library to create the static/shared libraries Summary: The problem with using an object library for doing this is that it prevents the shared library and the static library from being built with the right default flags. For example, CMake will build shared libraries with -fPIC by default, but not static libraries. Using an object library to create the shared library will prevent the right default flags for shared libraries from being used. As a side effect, this patch also localizes the logic related to building a hermetic static library to the static library case, making clear that this has no effect on the shared library. Reviewers: phosek, EricWF Subscribers: mgorny, christof, jkorous, dexonsmith, jdoerfert, libcxx-commits Differential Revision: https://reviews.llvm.org/D59248 llvm-svn: 356150
2019-03-14 22:19:08 +08:00
split_list(LIBCXX_COMPILE_FLAGS)
split_list(LIBCXX_LINK_FLAGS)
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
# Build the shared library.
if (LIBCXX_ENABLE_SHARED)
[libc++] Do not share an object library to create the static/shared libraries Summary: The problem with using an object library for doing this is that it prevents the shared library and the static library from being built with the right default flags. For example, CMake will build shared libraries with -fPIC by default, but not static libraries. Using an object library to create the shared library will prevent the right default flags for shared libraries from being used. As a side effect, this patch also localizes the logic related to building a hermetic static library to the static library case, making clear that this has no effect on the shared library. Reviewers: phosek, EricWF Subscribers: mgorny, christof, jkorous, dexonsmith, jdoerfert, libcxx-commits Differential Revision: https://reviews.llvm.org/D59248 llvm-svn: 356150
2019-03-14 22:19:08 +08:00
add_library(cxx_shared SHARED ${exclude_from_all} ${LIBCXX_SOURCES} ${LIBCXX_HEADERS})
[libc++] Use a proper CMake target to represent libc++ headers Instead of having complex logic around how to include the libc++ headers and __config_site, handle that by defining cxx-headers as an INTERFACE library and linking against it. After this patch, linking against cxx-headers is sufficient to get the right __config_site include and include paths for libc++. Differential Revision: https://reviews.llvm.org/D82702
2020-06-27 04:05:55 +08:00
target_link_libraries(cxx_shared PUBLIC cxx-headers
PRIVATE ${LIBCXX_LIBRARIES})
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
set_target_properties(cxx_shared
PROPERTIES
[libc++] Do not share an object library to create the static/shared libraries Summary: The problem with using an object library for doing this is that it prevents the shared library and the static library from being built with the right default flags. For example, CMake will build shared libraries with -fPIC by default, but not static libraries. Using an object library to create the shared library will prevent the right default flags for shared libraries from being used. As a side effect, this patch also localizes the logic related to building a hermetic static library to the static library case, making clear that this has no effect on the shared library. Reviewers: phosek, EricWF Subscribers: mgorny, christof, jkorous, dexonsmith, jdoerfert, libcxx-commits Differential Revision: https://reviews.llvm.org/D59248 llvm-svn: 356150
2019-03-14 22:19:08 +08:00
COMPILE_FLAGS "${LIBCXX_COMPILE_FLAGS}"
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
LINK_FLAGS "${LIBCXX_LINK_FLAGS}"
OUTPUT_NAME "c++"
VERSION "${LIBCXX_ABI_VERSION}.0"
SOVERSION "${LIBCXX_ABI_VERSION}"
[libc++][CMake] Do not define `cxx_shared_EXPORTS` when building the shared library CMake will define -Dcxx_shared_EXPORTS when building the shared library by default. In theory, this is used to signal to the library that we're building a shared library and that dllimport/dllexport should be used. However, we already have our own way of doing that, so I'm removing this define to avoid meaningless command line arguments in the build. llvm-svn: 356167
2019-03-15 01:15:47 +08:00
DEFINE_SYMBOL ""
Add CMake build and fix major Linux blockers. llvm-svn: 121510
2010-12-11 03:47:54 +08:00
)
[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
cxx_add_common_build_flags(cxx_shared)
[libc++] Do not share an object library to create the static/shared libraries Summary: The problem with using an object library for doing this is that it prevents the shared library and the static library from being built with the right default flags. For example, CMake will build shared libraries with -fPIC by default, but not static libraries. Using an object library to create the shared library will prevent the right default flags for shared libraries from being used. As a side effect, this patch also localizes the logic related to building a hermetic static library to the static library case, making clear that this has no effect on the shared library. Reviewers: phosek, EricWF Subscribers: mgorny, christof, jkorous, dexonsmith, jdoerfert, libcxx-commits Differential Revision: https://reviews.llvm.org/D59248 llvm-svn: 356150
2019-03-14 22:19:08 +08:00
cxx_set_common_defines(cxx_shared)
[CMake] Split linked libraries for shared and static libc++ Some linker libraries are only needed for shared libc++, some only for static libc++, combining these together in LIBCXX_LIBRARIES and LIBCXX_INTERFACE_LIBRARIES can introduce unnecessary dependencies. This changes splits those up into LIBCXX_SHARED_LIBRARIES and LIBCXX_STATIC_LIBRARIES matching what libc++abi already does. Differential Revision: https://reviews.llvm.org/D57872 llvm-svn: 358614
2019-04-18 05:41:09 +08:00
# Link against LLVM libunwind
if (LIBCXXABI_USE_LLVM_UNWINDER)
if (NOT LIBCXXABI_STATICALLY_LINK_UNWINDER_IN_SHARED_LIBRARY AND (TARGET unwind_shared OR HAVE_LIBUNWIND))
[libc++][CMake] Refactor how we link against system libraries Summary: Instead of populating the global LIBCXX_LIBRARIES, we use the link-time dependency management built into CMake to propagate link flags. This leads to a cleaner and easier-to-follow build. Reviewers: phosek, smeenai, EricWF Subscribers: mgorny, christof, jkorous, dexonsmith, jfb, mstorsjo, libcxx-commits Tags: #libc Differential Revision: https://reviews.llvm.org/D60969 llvm-svn: 359571
2019-04-30 23:44:19 +08:00
target_link_libraries(cxx_shared PUBLIC unwind_shared)
[CMake] Split linked libraries for shared and static libc++ Some linker libraries are only needed for shared libc++, some only for static libc++, combining these together in LIBCXX_LIBRARIES and LIBCXX_INTERFACE_LIBRARIES can introduce unnecessary dependencies. This changes splits those up into LIBCXX_SHARED_LIBRARIES and LIBCXX_STATIC_LIBRARIES matching what libc++abi already does. Differential Revision: https://reviews.llvm.org/D57872 llvm-svn: 358614
2019-04-18 05:41:09 +08:00
elseif (LIBCXXABI_STATICALLY_LINK_UNWINDER_IN_SHARED_LIBRARY AND (TARGET unwind_static OR HAVE_LIBUNWIND))
# libunwind is already included in libc++abi
else()
[libc++] Move the linker script generation step to CMake Summary: This allows the linker script generation to query CMake properties (specifically the dependencies of libc++.so) instead of having to carry these dependencies around manually in global variables. Notice the removal of the LIBCXX_INTERFACE_LIBRARIES global variable. Reviewers: phosek, EricWF Subscribers: mgorny, christof, jkorous, dexonsmith, libcxx-commits Tags: #libc Differential Revision: https://reviews.llvm.org/D68343 llvm-svn: 374116
2019-10-09 05:10:20 +08:00
target_link_libraries(cxx_shared PUBLIC unwind)
[CMake] Split linked libraries for shared and static libc++ Some linker libraries are only needed for shared libc++, some only for static libc++, combining these together in LIBCXX_LIBRARIES and LIBCXX_INTERFACE_LIBRARIES can introduce unnecessary dependencies. This changes splits those up into LIBCXX_SHARED_LIBRARIES and LIBCXX_STATIC_LIBRARIES matching what libc++abi already does. Differential Revision: https://reviews.llvm.org/D57872 llvm-svn: 358614
2019-04-18 05:41:09 +08:00
endif()
endif()
[libc++] Localize CMake code only related to the shared library Summary: There's a lot of CMake logic that's only relevant to the shared library, yet it was using a code path and setting variables that impact both the shared and the static libraries. This patch moves this logic so that it clearly only impacts the shared library. Reviewers: phosek, smeenai, EricWF Subscribers: mgorny, christof, jkorous, dexonsmith, libcxx-commits Tags: #libc Differential Revision: https://reviews.llvm.org/D60276 llvm-svn: 357811
2019-04-06 04:29:54 +08:00
# Link against libc++abi
if (LIBCXX_STATICALLY_LINK_ABI_IN_SHARED_LIBRARY)
if (APPLE)
[CMake] Fix statically linking in libcxxabi if built separately In this case, CMake doesn't know about the c++abi target within the same CMake run. This reverts this aspect back to how it was before SVN r357811. Differential Revision: https://reviews.llvm.org/D60448 llvm-svn: 358009
2019-04-09 22:31:09 +08:00
target_link_libraries(cxx_shared PRIVATE "-Wl,-force_load" "${LIBCXX_CXX_STATIC_ABI_LIBRARY}")
[libc++] Localize CMake code only related to the shared library Summary: There's a lot of CMake logic that's only relevant to the shared library, yet it was using a code path and setting variables that impact both the shared and the static libraries. This patch moves this logic so that it clearly only impacts the shared library. Reviewers: phosek, smeenai, EricWF Subscribers: mgorny, christof, jkorous, dexonsmith, libcxx-commits Tags: #libc Differential Revision: https://reviews.llvm.org/D60276 llvm-svn: 357811
2019-04-06 04:29:54 +08:00
else()
[CMake] Fix statically linking in libcxxabi if built separately In this case, CMake doesn't know about the c++abi target within the same CMake run. This reverts this aspect back to how it was before SVN r357811. Differential Revision: https://reviews.llvm.org/D60448 llvm-svn: 358009
2019-04-09 22:31:09 +08:00
target_link_libraries(cxx_shared PRIVATE "-Wl,--whole-archive,-Bstatic" "${LIBCXX_CXX_STATIC_ABI_LIBRARY}" "-Wl,-Bdynamic,--no-whole-archive")
[libc++] Localize CMake code only related to the shared library Summary: There's a lot of CMake logic that's only relevant to the shared library, yet it was using a code path and setting variables that impact both the shared and the static libraries. This patch moves this logic so that it clearly only impacts the shared library. Reviewers: phosek, smeenai, EricWF Subscribers: mgorny, christof, jkorous, dexonsmith, libcxx-commits Tags: #libc Differential Revision: https://reviews.llvm.org/D60276 llvm-svn: 357811
2019-04-06 04:29:54 +08:00
endif()
else()
[libc++][CMake] Refactor how we link against system libraries Summary: Instead of populating the global LIBCXX_LIBRARIES, we use the link-time dependency management built into CMake to propagate link flags. This leads to a cleaner and easier-to-follow build. Reviewers: phosek, smeenai, EricWF Subscribers: mgorny, christof, jkorous, dexonsmith, jfb, mstorsjo, libcxx-commits Tags: #libc Differential Revision: https://reviews.llvm.org/D60969 llvm-svn: 359571
2019-04-30 23:44:19 +08:00
target_link_libraries(cxx_shared PUBLIC "${LIBCXX_CXX_SHARED_ABI_LIBRARY}")
[libc++] Localize CMake code only related to the shared library Summary: There's a lot of CMake logic that's only relevant to the shared library, yet it was using a code path and setting variables that impact both the shared and the static libraries. This patch moves this logic so that it clearly only impacts the shared library. Reviewers: phosek, smeenai, EricWF Subscribers: mgorny, christof, jkorous, dexonsmith, libcxx-commits Tags: #libc Differential Revision: https://reviews.llvm.org/D60276 llvm-svn: 357811
2019-04-06 04:29:54 +08:00
endif()
# Maybe re-export symbols from libc++abi
[libc++] Fix broken build when merging libc++abi into libc++ on Apple
2021-01-23 01:39:17 +08:00
# In particular, we don't re-export the symbols if libc++abi is merged statically
# into libc++ because in that case there's no dylib to re-export from.
[libc++] Localize CMake code only related to the shared library Summary: There's a lot of CMake logic that's only relevant to the shared library, yet it was using a code path and setting variables that impact both the shared and the static libraries. This patch moves this logic so that it clearly only impacts the shared library. Reviewers: phosek, smeenai, EricWF Subscribers: mgorny, christof, jkorous, dexonsmith, libcxx-commits Tags: #libc Differential Revision: https://reviews.llvm.org/D60276 llvm-svn: 357811
2019-04-06 04:29:54 +08:00
if (APPLE AND (LIBCXX_CXX_ABI_LIBNAME STREQUAL "libcxxabi" OR
LIBCXX_CXX_ABI_LIBNAME STREQUAL "default")
[libc++] Fix broken build when merging libc++abi into libc++ on Apple
2021-01-23 01:39:17 +08:00
AND NOT DEFINED LIBCXX_OSX_REEXPORT_LIBCXXABI_SYMBOLS
AND NOT LIBCXX_STATICALLY_LINK_ABI_IN_SHARED_LIBRARY)
[libc++] Localize CMake code only related to the shared library Summary: There's a lot of CMake logic that's only relevant to the shared library, yet it was using a code path and setting variables that impact both the shared and the static libraries. This patch moves this logic so that it clearly only impacts the shared library. Reviewers: phosek, smeenai, EricWF Subscribers: mgorny, christof, jkorous, dexonsmith, libcxx-commits Tags: #libc Differential Revision: https://reviews.llvm.org/D60276 llvm-svn: 357811
2019-04-06 04:29:54 +08:00
set(LIBCXX_OSX_REEXPORT_LIBCXXABI_SYMBOLS ON)
endif()
if (LIBCXX_OSX_REEXPORT_LIBCXXABI_SYMBOLS)
target_link_libraries(cxx_shared PRIVATE
[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
"-Wl,-unexported_symbols_list,${CMAKE_CURRENT_SOURCE_DIR}/../lib/libc++unexp.exp"
[libc++] Fix the no-exceptions build of libc++ on Apple We previously tried re-exporting symbols that didn't exist when exceptions were disabled. Note that building libc++abi without exceptions still doesn't work when linking against the default-provided libSystem.dylib, because it transitively depends on libobjc.dylib, and that requires __gxx_personality_v0. But building libc++abi with exceptions and libc++ without exceptions does work.
2020-04-20 17:22:20 +08:00
"-Wl,-reexported_symbols_list,${CMAKE_CURRENT_SOURCE_DIR}/../lib/libc++abi.v${LIBCXX_LIBCPPABI_VERSION}.exp"
[libc++/abi] Revert "[libc++] Move the weak symbols list to libc++abi" This reverts commit c7d4aa711a. I am still investigating the issue, but it looks like that commit has an interaction with ld64 that causes new/delete weak re-exports not to work properly anymore. This is weird because this commit did not touch the exports of new/delete -- I am still investigating.
2020-10-05 23:42:13 +08:00
"-Wl,-force_symbols_not_weak_list,${CMAKE_CURRENT_SOURCE_DIR}/../lib/notweak.exp"
"-Wl,-force_symbols_weak_list,${CMAKE_CURRENT_SOURCE_DIR}/../lib/weak.exp")
[libc++] Refactor the run-buildbot script to make it more modular, and run the benchmarks As a fly-by fix, unbreak the benchmarks on Apple platforms. Differential Revision: https://reviews.llvm.org/D90043
2020-10-23 22:02:14 +08:00
[libc++] Add a CI jobs to test the Standalone builds
2020-10-24 04:27:41 +08:00
target_link_libraries(cxx_shared PRIVATE $<TARGET_NAME_IF_EXISTS:cxxabi-reexports>)
[libc++] Localize CMake code only related to the shared library Summary: There's a lot of CMake logic that's only relevant to the shared library, yet it was using a code path and setting variables that impact both the shared and the static libraries. This patch moves this logic so that it clearly only impacts the shared library. Reviewers: phosek, smeenai, EricWF Subscribers: mgorny, christof, jkorous, dexonsmith, libcxx-commits Tags: #libc Differential Revision: https://reviews.llvm.org/D60276 llvm-svn: 357811
2019-04-06 04:29:54 +08:00
endif()
[libc++] Move the linker script generation step to CMake Summary: This allows the linker script generation to query CMake properties (specifically the dependencies of libc++.so) instead of having to carry these dependencies around manually in global variables. Notice the removal of the LIBCXX_INTERFACE_LIBRARIES global variable. Reviewers: phosek, EricWF Subscribers: mgorny, christof, jkorous, dexonsmith, libcxx-commits Tags: #libc Differential Revision: https://reviews.llvm.org/D68343 llvm-svn: 374116
2019-10-09 05:10:20 +08:00
# Generate a linker script in place of a libc++.so symlink.
[libc++] Localize CMake code only related to the shared library Summary: There's a lot of CMake logic that's only relevant to the shared library, yet it was using a code path and setting variables that impact both the shared and the static libraries. This patch moves this logic so that it clearly only impacts the shared library. Reviewers: phosek, smeenai, EricWF Subscribers: mgorny, christof, jkorous, dexonsmith, libcxx-commits Tags: #libc Differential Revision: https://reviews.llvm.org/D60276 llvm-svn: 357811
2019-04-06 04:29:54 +08:00
if (LIBCXX_ENABLE_ABI_LINKER_SCRIPT)
[libc++] Move the linker script generation step to CMake Summary: This allows the linker script generation to query CMake properties (specifically the dependencies of libc++.so) instead of having to carry these dependencies around manually in global variables. Notice the removal of the LIBCXX_INTERFACE_LIBRARIES global variable. Reviewers: phosek, EricWF Subscribers: mgorny, christof, jkorous, dexonsmith, libcxx-commits Tags: #libc Differential Revision: https://reviews.llvm.org/D68343 llvm-svn: 374116
2019-10-09 05:10:20 +08:00
include(DefineLinkerScript)
define_linker_script(cxx_shared)
[libc++] Localize CMake code only related to the shared library Summary: There's a lot of CMake logic that's only relevant to the shared library, yet it was using a code path and setting variables that impact both the shared and the static libraries. This patch moves this logic so that it clearly only impacts the shared library. Reviewers: phosek, smeenai, EricWF Subscribers: mgorny, christof, jkorous, dexonsmith, libcxx-commits Tags: #libc Differential Revision: https://reviews.llvm.org/D60276 llvm-svn: 357811
2019-04-06 04:29:54 +08:00
endif()
[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
list(APPEND LIBCXX_BUILD_TARGETS "cxx_shared")
build: make cross-compiling to Windows work on Linux Disable the manifest bundling on Windows when cross-compiling on not-Windows. With this, it is possible to execute the link command from CMake which will use cmake to invoke the manifest tool to generate a manifest and pass that to the linker. llvm-svn: 290836
2017-01-03 05:09:19 +08:00
if(WIN32 AND NOT MINGW AND NOT "${CMAKE_HOST_SYSTEM_NAME}" STREQUAL "Windows")
# Since we most likely do not have a mt.exe replacement, disable the
# manifest bundling. This allows a normal cmake invocation to pass which
# will attempt to use the manifest tool to generate the bundled manifest
set_target_properties(cxx_shared PROPERTIES
APPEND_STRING PROPERTY LINK_FLAGS " /MANIFEST:NO")
endif()
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
endif()
[libcxx] Consistently set CMAKE_STATIC_LIBRARY_PREFIX regardless of LIBCXX_ENABLE_STATIC CMAKE_STATIC_LIBRARY_PREFIX affects the naming of all static libs (in MSVC configurations), including c++experimental, which only is produced as static regardless of LIBCXX_ENABLE_STATIC. Differential Revision: https://reviews.llvm.org/D99176
2021-03-23 19:23:16 +08:00
set(CMAKE_STATIC_LIBRARY_PREFIX "lib")
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
# Build the static library.
if (LIBCXX_ENABLE_STATIC)
[libc++] Do not share an object library to create the static/shared libraries Summary: The problem with using an object library for doing this is that it prevents the shared library and the static library from being built with the right default flags. For example, CMake will build shared libraries with -fPIC by default, but not static libraries. Using an object library to create the shared library will prevent the right default flags for shared libraries from being used. As a side effect, this patch also localizes the logic related to building a hermetic static library to the static library case, making clear that this has no effect on the shared library. Reviewers: phosek, EricWF Subscribers: mgorny, christof, jkorous, dexonsmith, jdoerfert, libcxx-commits Differential Revision: https://reviews.llvm.org/D59248 llvm-svn: 356150
2019-03-14 22:19:08 +08:00
add_library(cxx_static STATIC ${exclude_from_all} ${LIBCXX_SOURCES} ${LIBCXX_HEADERS})
[libc++] Use a proper CMake target to represent libc++ headers Instead of having complex logic around how to include the libc++ headers and __config_site, handle that by defining cxx-headers as an INTERFACE library and linking against it. After this patch, linking against cxx-headers is sufficient to get the right __config_site include and include paths for libc++. Differential Revision: https://reviews.llvm.org/D82702
2020-06-27 04:05:55 +08:00
target_link_libraries(cxx_static PUBLIC cxx-headers
PRIVATE ${LIBCXX_LIBRARIES})
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
set_target_properties(cxx_static
PROPERTIES
[libc++] Do not share an object library to create the static/shared libraries Summary: The problem with using an object library for doing this is that it prevents the shared library and the static library from being built with the right default flags. For example, CMake will build shared libraries with -fPIC by default, but not static libraries. Using an object library to create the shared library will prevent the right default flags for shared libraries from being used. As a side effect, this patch also localizes the logic related to building a hermetic static library to the static library case, making clear that this has no effect on the shared library. Reviewers: phosek, EricWF Subscribers: mgorny, christof, jkorous, dexonsmith, jdoerfert, libcxx-commits Differential Revision: https://reviews.llvm.org/D59248 llvm-svn: 356150
2019-03-14 22:19:08 +08:00
COMPILE_FLAGS "${LIBCXX_COMPILE_FLAGS}"
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
LINK_FLAGS "${LIBCXX_LINK_FLAGS}"
libcxx: fix bootstrapping for mingw-w64 Differential Revision: https://reviews.llvm.org/D33388 llvm-svn: 303928
2017-05-26 06:37:15 +08:00
OUTPUT_NAME "c++"
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
)
[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
cxx_add_common_build_flags(cxx_static)
[libc++][CMake] Fix typo introduced in r356150 That typo broke the build when the shared library build was disabled. llvm-svn: 356155
2019-03-14 22:52:26 +08:00
cxx_set_common_defines(cxx_static)
[libc++] Do not share an object library to create the static/shared libraries Summary: The problem with using an object library for doing this is that it prevents the shared library and the static library from being built with the right default flags. For example, CMake will build shared libraries with -fPIC by default, but not static libraries. Using an object library to create the shared library will prevent the right default flags for shared libraries from being used. As a side effect, this patch also localizes the logic related to building a hermetic static library to the static library case, making clear that this has no effect on the shared library. Reviewers: phosek, EricWF Subscribers: mgorny, christof, jkorous, dexonsmith, jdoerfert, libcxx-commits Differential Revision: https://reviews.llvm.org/D59248 llvm-svn: 356150
2019-03-14 22:19:08 +08:00
if (LIBCXX_HERMETIC_STATIC_LIBRARY)
[libcxx] Don't use -fvisibility-global-new-delete-hidden when not defining them When builing the hermetic static library, the compiler switch -fvisibility-global-new-delete-hidden is necessary to get the new and delete operator definitions made correctly. However, when those definitions are not included in the library, then this switch does harm. With lld (though not all linkers) setting STV_HIDDEN on SHN_UNDEF symbols makes it an error to leave them undefined or defined via dynamic linking that should generate PLTs for -shared linking (lld makes this a hard error even without -z defs). Though leaving the symbols undefined would usually work in practice if the linker were to allow it (and the user didn't pass -z defs), this actually indicates a real problem that could bite some target configurations more subtly at runtime. For example, x86-32 ELF -fpic code generation uses hidden visibility on declarations in the caller's scope as a signal that the call will never be resolved to a PLT entry and so doesn't have to meet the special ABI requirements for PLT calls (setting %ebx). Since these functions might actually be resolved to PLT entries at link time (we don't know what the user is linking in when the hermetic library doesn't provide all the symbols itself), it's not safe for the compiler to treat their declarations at call sites as having hidden visibility. Differential Revision: https://reviews.llvm.org/D61571 llvm-svn: 360003
2019-05-06 09:22:28 +08:00
# If the hermetic library doesn't define the operator new/delete functions
# then its code shouldn't declare them with hidden visibility. They might
# actually be provided by a shared library at link time.
if (LIBCXX_ENABLE_NEW_DELETE_DEFINITIONS)
append_flags_if_supported(CXX_STATIC_LIBRARY_FLAGS -fvisibility-global-new-delete-hidden)
endif()
[libc++] Do not share an object library to create the static/shared libraries Summary: The problem with using an object library for doing this is that it prevents the shared library and the static library from being built with the right default flags. For example, CMake will build shared libraries with -fPIC by default, but not static libraries. Using an object library to create the shared library will prevent the right default flags for shared libraries from being used. As a side effect, this patch also localizes the logic related to building a hermetic static library to the static library case, making clear that this has no effect on the shared library. Reviewers: phosek, EricWF Subscribers: mgorny, christof, jkorous, dexonsmith, jdoerfert, libcxx-commits Differential Revision: https://reviews.llvm.org/D59248 llvm-svn: 356150
2019-03-14 22:19:08 +08:00
target_compile_options(cxx_static PRIVATE ${CXX_STATIC_LIBRARY_FLAGS})
target_compile_definitions(cxx_static PRIVATE _LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS)
endif()
[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
list(APPEND LIBCXX_BUILD_TARGETS "cxx_static")
Make LIBCXX_ENABLE_STATIC_ABI_LIBRARY merge libc++.a and libc++abi.a llvm-svn: 287373
2016-11-19 03:53:45 +08:00
# Attempt to merge the libc++.a archive and the ABI library archive into one.
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
if (LIBCXX_STATICALLY_LINK_ABI_IN_STATIC_LIBRARY)
Make LIBCXX_ENABLE_STATIC_ABI_LIBRARY merge libc++.a and libc++abi.a llvm-svn: 287373
2016-11-19 03:53:45 +08:00
set(MERGE_ARCHIVES_SEARCH_PATHS "")
if (LIBCXX_CXX_ABI_LIBRARY_PATH)
set(MERGE_ARCHIVES_SEARCH_PATHS "-L${LIBCXX_CXX_ABI_LIBRARY_PATH}")
endif()
[CMake] Differentiate between static and shared libc++abi This addresses the issue introduced in r354212 which broke the case when static libc++abi is merged into static libc++, but shared libc++ is linked against shared libc++. There are 4 different possible combinations which is difficult to capture using a single variable. This change splits LIBCXX_CXX_ABI_LIBRARY into two: LIBCXX_CXX_SHARED_ABI_LIBRARY and LIBCXX_CXX_STATIC_ABI_LIBRARY to handle the shared and static cases. This in turn allows simplification of some of the logic around merging of static archives. Differential Revision: https://reviews.llvm.org/D60114 llvm-svn: 357556
2019-04-03 09:33:14 +08:00
if (TARGET "${LIBCXX_CXX_STATIC_ABI_LIBRARY}" OR HAVE_LIBCXXABI)
set(MERGE_ARCHIVES_ABI_TARGET "$<TARGET_LINKER_FILE:${LIBCXX_CXX_STATIC_ABI_LIBRARY}>")
Make LIBCXX_ENABLE_STATIC_ABI_LIBRARY merge libc++.a and libc++abi.a llvm-svn: 287373
2016-11-19 03:53:45 +08:00
else()
build: use the platform dependent library prefix/suffix Use the cmake variables to get the platform dependent values for the static library prefix and suffix, which can be different from the Unix preference for "lib", ".a" (e.g. Windows uses "", ".lib" respectively). llvm-svn: 290939
2017-01-04 13:49:57 +08:00
set(MERGE_ARCHIVES_ABI_TARGET
[CMake] Differentiate between static and shared libc++abi This addresses the issue introduced in r354212 which broke the case when static libc++abi is merged into static libc++, but shared libc++ is linked against shared libc++. There are 4 different possible combinations which is difficult to capture using a single variable. This change splits LIBCXX_CXX_ABI_LIBRARY into two: LIBCXX_CXX_SHARED_ABI_LIBRARY and LIBCXX_CXX_STATIC_ABI_LIBRARY to handle the shared and static cases. This in turn allows simplification of some of the logic around merging of static archives. Differential Revision: https://reviews.llvm.org/D60114 llvm-svn: 357556
2019-04-03 09:33:14 +08:00
"${CMAKE_STATIC_LIBRARY_PREFIX}${LIBCXX_CXX_STATIC_ABI_LIBRARY}${CMAKE_STATIC_LIBRARY_SUFFIX}")
[CMake][runtimes] Add file level dependency to merge_archives commands Both libc++ and libc++abi have options of merging with another archive. In the case of libc++abi, libunwind can be merged into it and in the case of libc++, libc++abi can be merged into it. This is realized using add_custom_command with POST_BUILD and the usage of the CMake generator expression TARGET_LINKER_FILE in the arguments. For such generator expressions CMake doc states: "This target-level dependency does NOT add a file-level dependency that would cause the custom command to re-run whenever the executable is recompiled" [1] This patch adds a DEPENDS argument to both add_custom_command invocations so that the archives also have a file-level dependency on the target they are merging with. That way, changes in say, libunwind source code, will be updated in the libc++abi and/or libc++ static libraries as well. [1] https://cmake.org/cmake/help/v3.20/command/add_custom_command.html Differential Revision: https://reviews.llvm.org/D98129
2021-03-19 01:51:10 +08:00
if (LIBCXX_CXX_ABI_LIBRARY_PATH)
set(MERGE_ARCHIVES_ABI_TARGET "${LIBCXX_CXX_ABI_LIBRARY_PATH}/${MERGE_ARCHIVES_ABI_TARGET}")
endif ()
Make LIBCXX_ENABLE_STATIC_ABI_LIBRARY merge libc++.a and libc++abi.a llvm-svn: 287373
2016-11-19 03:53:45 +08:00
endif()
[libcxx] Use libtool when merging archives on Apple platforms ar doesn't produce the correct results when used for linking static archives on Apple platforms, so instead use libtool -static which is the official way to build static archives on those platforms. Differential Revision: https://reviews.llvm.org/D62770 llvm-svn: 362311
2019-06-02 09:14:31 +08:00
if (APPLE)
set(MERGE_ARCHIVES_LIBTOOL "--use-libtool" "--libtool" "${CMAKE_LIBTOOL}")
endif()
Make LIBCXX_ENABLE_STATIC_ABI_LIBRARY merge libc++.a and libc++abi.a llvm-svn: 287373
2016-11-19 03:53:45 +08:00
add_custom_command(TARGET cxx_static POST_BUILD
COMMAND
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
${Python3_EXECUTABLE} ${LIBCXX_SOURCE_DIR}/utils/merge_archives.py
Make LIBCXX_ENABLE_STATIC_ABI_LIBRARY merge libc++.a and libc++abi.a llvm-svn: 287373
2016-11-19 03:53:45 +08:00
ARGS
-o $<TARGET_LINKER_FILE:cxx_static>
Use CMAKE_AR instead of the system default 'ar' for merging static libraries Using the system default 'ar' might not be the right choice when cross compiling. Don't prepend the ar options by a dash, not all ar implementations support that (llvm-ar doesn't). Also pass the 's' option when creating the merged library, to create an index. Differential Revision: https://reviews.llvm.org/D37134 llvm-svn: 313122
2017-09-13 14:55:44 +08:00
--ar "${CMAKE_AR}"
[libcxx] Use libtool when merging archives on Apple platforms ar doesn't produce the correct results when used for linking static archives on Apple platforms, so instead use libtool -static which is the official way to build static archives on those platforms. Differential Revision: https://reviews.llvm.org/D62770 llvm-svn: 362311
2019-06-02 09:14:31 +08:00
${MERGE_ARCHIVES_LIBTOOL}
Make LIBCXX_ENABLE_STATIC_ABI_LIBRARY merge libc++.a and libc++abi.a llvm-svn: 287373
2016-11-19 03:53:45 +08:00
"$<TARGET_LINKER_FILE:cxx_static>"
"${MERGE_ARCHIVES_ABI_TARGET}"
"${MERGE_ARCHIVES_SEARCH_PATHS}"
WORKING_DIRECTORY ${LIBCXX_BUILD_DIR}
[CMake][runtimes] Add file level dependency to merge_archives commands Both libc++ and libc++abi have options of merging with another archive. In the case of libc++abi, libunwind can be merged into it and in the case of libc++, libc++abi can be merged into it. This is realized using add_custom_command with POST_BUILD and the usage of the CMake generator expression TARGET_LINKER_FILE in the arguments. For such generator expressions CMake doc states: "This target-level dependency does NOT add a file-level dependency that would cause the custom command to re-run whenever the executable is recompiled" [1] This patch adds a DEPENDS argument to both add_custom_command invocations so that the archives also have a file-level dependency on the target they are merging with. That way, changes in say, libunwind source code, will be updated in the libc++abi and/or libc++ static libraries as well. [1] https://cmake.org/cmake/help/v3.20/command/add_custom_command.html Differential Revision: https://reviews.llvm.org/D98129
2021-03-19 01:51:10 +08:00
DEPENDS ${MERGE_ARCHIVES_ABI_TARGET}
Make LIBCXX_ENABLE_STATIC_ABI_LIBRARY merge libc++.a and libc++abi.a llvm-svn: 287373
2016-11-19 03:53:45 +08:00
)
endif()
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
endif()
Add libc++fs to the test deps, and not to the target 'cxx'. llvm-svn: 338096
2018-07-27 11:47:46 +08:00
# Add a meta-target for both libraries.
[libc++] Use a proper CMake target to represent libc++ headers Instead of having complex logic around how to include the libc++ headers and __config_site, handle that by defining cxx-headers as an INTERFACE library and linking against it. After this patch, linking against cxx-headers is sufficient to get the right __config_site include and include paths for libc++. Differential Revision: https://reviews.llvm.org/D82702
2020-06-27 04:05:55 +08:00
add_custom_target(cxx DEPENDS ${LIBCXX_BUILD_TARGETS})
Add libc++fs to the test deps, and not to the target 'cxx'. llvm-svn: 338096
2018-07-27 11:47:46 +08:00
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
if (LIBCXX_ENABLE_EXPERIMENTAL_LIBRARY)
[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
set(LIBCXX_EXPERIMENTAL_SOURCES
experimental/memory_resource.cpp
)
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
add_library(cxx_experimental STATIC ${LIBCXX_EXPERIMENTAL_SOURCES})
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
if (LIBCXX_ENABLE_SHARED)
[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(cxx_experimental PRIVATE cxx_shared)
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
else()
[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(cxx_experimental PRIVATE cxx_static)
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
endif()
[libcxx] Prefer C++14 over C++11 when building libc++experimental. Summary: Currently libc++experimental builds with C++11. This patch changes that to C++14 when supported by the compiler. Although nothing currently requires C++14 the upcoming <experimental/memory_resource> implementation would benefit from it. [1] Note that libc++.so continues to build with C++11 and is unaffected by this change. [1] <experimental/memory_resource> provides global resources which must exist for the entire lifetime of the program. In order to ensure that a global resource can be used during program termination there destructors must never be invoked. The only way to do this, while also allowing "constant initialization", is to use a C++14 union. Reviewers: mclow.lists Subscribers: pete, cfe-commits Differential Revision: http://reviews.llvm.org/D19992 llvm-svn: 269070
2016-05-11 00:17:43 +08:00
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
set_target_properties(cxx_experimental
PROPERTIES
[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
COMPILE_FLAGS "${LIBCXX_COMPILE_FLAGS}"
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
OUTPUT_NAME "c++experimental"
)
[libc++] Guard cxx_experimental settings behind LIBCXX_ENABLE_EXPERIMENTAL_LIBRARY If you explicitly set LIBCXX_ENABLE_EXPERIMENTAL_LIBRARY to OFF, your project will fail to configure because the cxx_experimental target doesn't exist. llvm-svn: 373809
2019-10-05 07:08:20 +08:00
cxx_add_common_build_flags(cxx_experimental)
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
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
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
[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)
[libcxx] Link target `cxx_external_threads` to `cxx-headers` for BUILD_EXTERNAL_THREAD_LIBRARY Fix compilation of libcxx when using -DLIBCXX_BUILD_EXTERNAL_THREAD_LIBRARY. Target `cxx_external_threads` gets linked to `cxx-headers` to include all needed headers and flags. Reviewed By: #libc, ldionne Differential Revision: https://reviews.llvm.org/D86773
2020-09-01 19:41:21 +08:00
set(LIBCXX_EXTERNAL_THREADING_SUPPORT_SOURCES
"${CMAKE_CURRENT_SOURCE_DIR}/../test/support/external_threads.cpp")
[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
if (LIBCXX_ENABLE_SHARED)
add_library(cxx_external_threads SHARED ${LIBCXX_EXTERNAL_THREADING_SUPPORT_SOURCES})
else()
add_library(cxx_external_threads STATIC ${LIBCXX_EXTERNAL_THREADING_SUPPORT_SOURCES})
endif()
set_target_properties(cxx_external_threads
PROPERTIES
LINK_FLAGS "${LIBCXX_LINK_FLAGS}"
COMPILE_FLAGS "${LIBCXX_COMPILE_FLAGS}"
OUTPUT_NAME "c++external_threads"
)
[libcxx] Link target `cxx_external_threads` to `cxx-headers` for BUILD_EXTERNAL_THREAD_LIBRARY Fix compilation of libcxx when using -DLIBCXX_BUILD_EXTERNAL_THREAD_LIBRARY. Target `cxx_external_threads` gets linked to `cxx-headers` to include all needed headers and flags. Reviewed By: #libc, ldionne Differential Revision: https://reviews.llvm.org/D86773
2020-09-01 19:41:21 +08:00
target_link_libraries(cxx_external_threads PRIVATE cxx-headers)
[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()
[libc++] Remove redundant if(LIBCXX_INSTALL_LIBRARY) The individual LIBCXX_INSTALL_(SHARED|STATIC)_LIBRARY are already dependent on whether LIBCXX_INSTALL_LIBRARY is ON or OFF.
2020-10-10 03:04:12 +08:00
if (LIBCXX_INSTALL_SHARED_LIBRARY)
install(TARGETS cxx_shared
[CMake] Remove {LIBCXX,LIBCXXABI,LIBUNWIND}_INSTALL_PREFIX These variables were introduced during early work on the runtimes build but were obsoleted by {LIBCXX,LIBCXXABI,LIBUNWIND}_INSTALL_LIBRARY_DIR. Differential Revision: https://reviews.llvm.org/D99697
2021-04-01 08:34:05 +08:00
ARCHIVE DESTINATION ${LIBCXX_INSTALL_LIBRARY_DIR} COMPONENT cxx
LIBRARY DESTINATION ${LIBCXX_INSTALL_LIBRARY_DIR} COMPONENT cxx
RUNTIME DESTINATION bin COMPONENT cxx)
[libc++] Remove redundant if(LIBCXX_INSTALL_LIBRARY) The individual LIBCXX_INSTALL_(SHARED|STATIC)_LIBRARY are already dependent on whether LIBCXX_INSTALL_LIBRARY is ON or OFF.
2020-10-10 03:04:12 +08:00
endif()
build: use multiple `install` rather than building up a list Rather than building up a list to iterate over later, just create multiple install commands based on the configuration. This makes it easier to see what is getting installed and allows for the install handling to be centralised. NFC llvm-svn: 365562
2019-07-10 05:43:01 +08:00
[libc++] Remove redundant if(LIBCXX_INSTALL_LIBRARY) The individual LIBCXX_INSTALL_(SHARED|STATIC)_LIBRARY are already dependent on whether LIBCXX_INSTALL_LIBRARY is ON or OFF.
2020-10-10 03:04:12 +08:00
if (LIBCXX_INSTALL_STATIC_LIBRARY)
install(TARGETS cxx_static
[CMake] Remove {LIBCXX,LIBCXXABI,LIBUNWIND}_INSTALL_PREFIX These variables were introduced during early work on the runtimes build but were obsoleted by {LIBCXX,LIBCXXABI,LIBUNWIND}_INSTALL_LIBRARY_DIR. Differential Revision: https://reviews.llvm.org/D99697
2021-04-01 08:34:05 +08:00
ARCHIVE DESTINATION ${LIBCXX_INSTALL_LIBRARY_DIR} COMPONENT cxx
LIBRARY DESTINATION ${LIBCXX_INSTALL_LIBRARY_DIR} COMPONENT cxx
RUNTIME DESTINATION bin COMPONENT cxx)
[libc++] Remove redundant if(LIBCXX_INSTALL_LIBRARY) The individual LIBCXX_INSTALL_(SHARED|STATIC)_LIBRARY are already dependent on whether LIBCXX_INSTALL_LIBRARY is ON or OFF.
2020-10-10 03:04:12 +08:00
endif()
build: use multiple `install` rather than building up a list Rather than building up a list to iterate over later, just create multiple install commands based on the configuration. This makes it easier to see what is getting installed and allows for the install handling to be centralised. NFC llvm-svn: 365562
2019-07-10 05:43:01 +08:00
[libc++] Remove redundant if(LIBCXX_INSTALL_LIBRARY) The individual LIBCXX_INSTALL_(SHARED|STATIC)_LIBRARY are already dependent on whether LIBCXX_INSTALL_LIBRARY is ON or OFF.
2020-10-10 03:04:12 +08:00
if(LIBCXX_INSTALL_EXPERIMENTAL_LIBRARY)
install(TARGETS cxx_experimental
[CMake] Remove {LIBCXX,LIBCXXABI,LIBUNWIND}_INSTALL_PREFIX These variables were introduced during early work on the runtimes build but were obsoleted by {LIBCXX,LIBCXXABI,LIBUNWIND}_INSTALL_LIBRARY_DIR. Differential Revision: https://reviews.llvm.org/D99697
2021-04-01 08:34:05 +08:00
LIBRARY DESTINATION ${LIBCXX_INSTALL_LIBRARY_DIR} COMPONENT cxx
ARCHIVE DESTINATION ${LIBCXX_INSTALL_LIBRARY_DIR} COMPONENT cxx
RUNTIME DESTINATION bin COMPONENT cxx)
[libc++] Remove redundant if(LIBCXX_INSTALL_LIBRARY) The individual LIBCXX_INSTALL_(SHARED|STATIC)_LIBRARY are already dependent on whether LIBCXX_INSTALL_LIBRARY is ON or OFF.
2020-10-10 03:04:12 +08:00
endif()
build: use multiple `install` rather than building up a list Rather than building up a list to iterate over later, just create multiple install commands based on the configuration. This makes it easier to see what is getting installed and allows for the install handling to be centralised. NFC llvm-svn: 365562
2019-07-10 05:43:01 +08:00
[libc++] Remove redundant if(LIBCXX_INSTALL_LIBRARY) The individual LIBCXX_INSTALL_(SHARED|STATIC)_LIBRARY are already dependent on whether LIBCXX_INSTALL_LIBRARY is ON or OFF.
2020-10-10 03:04:12 +08:00
# NOTE: This install command must go after the cxx install command otherwise
# it will not be executed after the library symlinks are installed.
if (LIBCXX_ENABLE_SHARED AND LIBCXX_ENABLE_ABI_LINKER_SCRIPT)
[libc++] Use generator expression to simplify the CMake code A comment was left for when we would require CMake >= 3, which we do now. I expect this should be a NFC. Differential Revision: https://reviews.llvm.org/D97341
2021-02-24 07:26:15 +08:00
install(FILES "$<TARGET_LINKER_FILE:cxx_shared>"
[CMake] Remove {LIBCXX,LIBCXXABI,LIBUNWIND}_INSTALL_PREFIX These variables were introduced during early work on the runtimes build but were obsoleted by {LIBCXX,LIBCXXABI,LIBUNWIND}_INSTALL_LIBRARY_DIR. Differential Revision: https://reviews.llvm.org/D99697
2021-04-01 08:34:05 +08:00
DESTINATION ${LIBCXX_INSTALL_LIBRARY_DIR}
[libc++] Remove redundant if(LIBCXX_INSTALL_LIBRARY) The individual LIBCXX_INSTALL_(SHARED|STATIC)_LIBRARY are already dependent on whether LIBCXX_INSTALL_LIBRARY is ON or OFF.
2020-10-10 03:04:12 +08:00
COMPONENT libcxx)
[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
endif()
[libcxx] Add "install-libcxx" target. Summary: Currently you can't install libc++ from within the LLVM tree without installing all of LLVM. This patch adds an install rule for libc++. Reviewers: mclow.lists, danalbert, jroelofs, EricWF Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D11697 llvm-svn: 245470
2015-08-20 01:41:53 +08:00
[libc++] Remove redundant if(LIBCXX_INSTALL_LIBRARY) The individual LIBCXX_INSTALL_(SHARED|STATIC)_LIBRARY are already dependent on whether LIBCXX_INSTALL_LIBRARY is ON or OFF.
2020-10-10 03:04:12 +08:00
if (NOT CMAKE_CONFIGURATION_TYPES)
[CMake] If you're not installing the libcxx library, exclude it from the "all" target so it doesn't get built when you run "ninja install" This is just a build dependency optimization. Running check-libcxx will still build libcxx and function as expected, it just removes libcxx from the all build and install targets. llvm-svn: 254628
2015-12-04 02:52:54 +08:00
if(LIBCXX_INSTALL_LIBRARY)
Fix dependencies on install-libcxx CMake target llvm-svn: 268363
2016-05-03 13:34:38 +08:00
set(lib_install_target cxx)
[CMake] If you're not installing the libcxx library, exclude it from the "all" target so it doesn't get built when you run "ninja install" This is just a build dependency optimization. Running check-libcxx will still build libcxx and function as expected, it just removes libcxx from the all build and install targets. llvm-svn: 254628
2015-12-04 02:52:54 +08:00
endif()
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
if (LIBCXX_INSTALL_EXPERIMENTAL_LIBRARY)
set(experimental_lib_install_target cxx_experimental)
endif()
[CMake] Create a separate install target for libcxx headers This change doesn't impact the behavior of the install-libcxx target which installs whichever libcxx components you build, it just adds a separate target to just install the headers. llvm-svn: 268124
2016-04-30 06:17:15 +08:00
if(LIBCXX_INSTALL_HEADERS)
[CMake] Be more consistent about naming targets and components Summary: The point of this patch is to have a consistent convention for naming build, check and install targets so that the targets can be constructed from the project name. This change renames a bunch of CMake components and targets from libcxx to cxx. For each renamed target I've added a convenience target that matches the old target name and depends on the new target. This will preserve function of the old targets so that the change doesn't break the world. We can evaluate if it is worth removing the extra targets later. Reviewers: EricWF Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D23699 llvm-svn: 279675
2016-08-25 06:17:06 +08:00
set(header_install_target install-cxx-headers)
[CMake] Create a separate install target for libcxx headers This change doesn't impact the behavior of the install-libcxx target which installs whichever libcxx components you build, it just adds a separate target to just install the headers. llvm-svn: 268124
2016-04-30 06:17:15 +08:00
endif()
[libc++] Install PSTL when installing libc++ with parallel algorithms enabled
2020-07-09 03:00:31 +08:00
if (LIBCXX_ENABLE_PARALLEL_ALGORITHMS)
set(pstl_install_target install-pstl)
endif()
[CMake] Be more consistent about naming targets and components Summary: The point of this patch is to have a consistent convention for naming build, check and install targets so that the targets can be constructed from the project name. This change renames a bunch of CMake components and targets from libcxx to cxx. For each renamed target I've added a convenience target that matches the old target name and depends on the new target. This will preserve function of the old targets so that the change doesn't break the world. We can evaluate if it is worth removing the extra targets later. Reviewers: EricWF Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D23699 llvm-svn: 279675
2016-08-25 06:17:06 +08:00
add_custom_target(install-cxx
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
DEPENDS ${lib_install_target}
${experimental_lib_install_target}
${header_install_target}
[libc++] Install PSTL when installing libc++ with parallel algorithms enabled
2020-07-09 03:00:31 +08:00
${pstl_install_target}
[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
COMMAND "${CMAKE_COMMAND}"
[CMake] Be more consistent about naming targets and components Summary: The point of this patch is to have a consistent convention for naming build, check and install targets so that the targets can be constructed from the project name. This change renames a bunch of CMake components and targets from libcxx to cxx. For each renamed target I've added a convenience target that matches the old target name and depends on the new target. This will preserve function of the old targets so that the change doesn't break the world. We can evaluate if it is worth removing the extra targets later. Reviewers: EricWF Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D23699 llvm-svn: 279675
2016-08-25 06:17:06 +08:00
-DCMAKE_INSTALL_COMPONENT=cxx
[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
-P "${LIBCXX_BINARY_DIR}/cmake_install.cmake")
[libc++] Create install-stripped targets LLVM is gaining install-*-stripped targets to perform stripped installs, and in order for this to be useful for install-distribution, all potential distribution components should have stripped installation targets. LLVM has a function to create these install targets, but since we can't use LLVM CMake functions in libc++, let's do it manually. Differential Revision: https://reviews.llvm.org/D40680 llvm-svn: 319959
2017-12-07 05:03:42 +08:00
add_custom_target(install-cxx-stripped
DEPENDS ${lib_install_target}
${experimental_lib_install_target}
${header_install_target}
[libc++] Install PSTL when installing libc++ with parallel algorithms enabled
2020-07-09 03:00:31 +08:00
${pstl_install_target}
[libc++] Create install-stripped targets LLVM is gaining install-*-stripped targets to perform stripped installs, and in order for this to be useful for install-distribution, all potential distribution components should have stripped installation targets. LLVM has a function to create these install targets, but since we can't use LLVM CMake functions in libc++, let's do it manually. Differential Revision: https://reviews.llvm.org/D40680 llvm-svn: 319959
2017-12-07 05:03:42 +08:00
COMMAND "${CMAKE_COMMAND}"
-DCMAKE_INSTALL_COMPONENT=cxx
-DCMAKE_INSTALL_DO_STRIP=1
-P "${LIBCXX_BINARY_DIR}/cmake_install.cmake")
[libcxx] Add "install-libcxx" target. Summary: Currently you can't install libc++ from within the LLVM tree without installing all of LLVM. This patch adds an install rule for libc++. Reviewers: mclow.lists, danalbert, jroelofs, EricWF Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D11697 llvm-svn: 245470
2015-08-20 01:41:53 +08:00
endif()