mirrors/llvm-project
0
0
Fork 0
mirror of https://github.com/llvm/llvm-project.git synced 2025-04-28 14:36:08 +00:00
Code Issues Projects Releases Wiki Activity
llvm-project/libcxx/utils/ci/run-buildbot

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

842 lines
28 KiB
Plaintext
Raw Normal View History

[libc++] Initial support for pre-commit CI with Buildkite This commit adds basic files and scripts that are used for the Buildkite pre-commit CI setup. This was tested to mostly work on a fork of llvm-project, however some adjustments will have to be made as we complete the real setup.
2020-09-23 09:20:03 -04:00
#!/usr/bin/env bash
[libc++][NFC] Use consistent layout for license in Python files Most Python files were using `# === [...]` instead of `#=== [...]` so I went with what was the most common in the codebase.
2024-09-04 16:47:20 -04:00
# ===----------------------------------------------------------------------===##
[libc++] Initial support for pre-commit CI with Buildkite This commit adds basic files and scripts that are used for the Buildkite pre-commit CI setup. This was tested to mostly work on a fork of llvm-project, however some adjustments will have to be made as we complete the real setup.
2020-09-23 09:20:03 -04:00
#
# Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
# See https://llvm.org/LICENSE.txt for license information.
# SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
#
[libc++][NFC] Use consistent layout for license in Python files Most Python files were using `# === [...]` instead of `#=== [...]` so I went with what was the most common in the codebase.
2024-09-04 16:47:20 -04:00
# ===----------------------------------------------------------------------===##
[libc++] Initial support for pre-commit CI with Buildkite This commit adds basic files and scripts that are used for the Buildkite pre-commit CI setup. This was tested to mostly work on a fork of llvm-project, however some adjustments will have to be made as we complete the real setup.
2020-09-23 09:20:03 -04:00
[libc++] Add output groups to run-buildbot (#111739) This improves the CI output by providing collapsable sections for sub-parts of our build. This was originally opened as #75233. Co-authored-by: eric <eric@efcs.ca>
2024-10-11 09:29:47 -04:00
set -e
[libc++] Add format check to CI Note: contrary to what I said previously, I didn't change .clang-format nor utils/generate_feature_test_macro_components.py script. Reviewed By: ldionne, #libc Differential Revision: https://reviews.llvm.org/D92229
2021-02-04 21:13:22 +01:00
set -o pipefail
[libc++] [test] Recommit the unsetting of LC_COLLATE in the builder script. This re-reverts one piece of 1b885573327d0f6b36f24ad23d243642f658750b, reapplying one piece of D101437 (but not the "service"-queue piece of it). It turns out that the behavior of `grep [^ -~]`, or even `grep [A-Z]`, depends on locale, specifically `LC_COLLATE`. So we want to make sure we're not in any weird locale, no matter what machine we're running on. Yes, "en_US.UTF-8" counts as weird! https://stackoverflow.com/questions/67320156/misbehavior-of-gnu-grep-when-grepping-for-ignores-spaces https://stackoverflow.com/questions/6799872/how-to-make-grep-a-z-independent-of-locale
2021-04-30 14:43:33 -04:00
unset LANG
unset LC_ALL
unset LC_COLLATE
[libc++] Initial support for pre-commit CI with Buildkite This commit adds basic files and scripts that are used for the Buildkite pre-commit CI setup. This was tested to mostly work on a fork of llvm-project, however some adjustments will have to be made as we complete the real setup.
2020-09-23 09:20:03 -04:00
[libc++] Allow customizing a few paths when running build bots This allows reusing run-buildbot for downstream testing as well.
2020-11-05 19:02:32 -05:00
PROGNAME="$(basename "${0}")"
function usage() {
cat <<EOF
Usage:
${PROGNAME} [options] <BUILDER>
[-h|--help] Display this help and exit.
--llvm-root <DIR> Path to the root of the LLVM monorepo. By default, we try
to figure it out based on the current working directory.
[libc++] Also allow customizing the build directory when running CI
2020-11-05 19:09:03 -05:00
--build-dir <DIR> The directory to use for building the library. By default,
this is '<llvm-root>/build/<builder>'.
[libc++][CI] Improves buildbot runner. Adds documentation and shows a help message when running the script without arguments. Lands parts of D139545.
2022-12-22 19:47:54 +01:00
Environment variables
CC The C compiler to use, this value is used by CMake. This
variable is optional.
[libc++][modules] Adds the C++23 std module. The patch is based on D144994. D151030 added the module definitions for the module std. This patch wires in the module and enables the basic testing. Some notable features are missing: - There is no test that libc++ can be fully imported as a module. - This lacks the parts for the std.compat module. - The module is not shipped with libc++. Implements parts of - P2465R3 Standard Library Modules std and std.compat Reviewed By: ldionne, aaronmondal, #libc Differential Revision: https://reviews.llvm.org/D151814
2023-02-28 20:29:26 +01:00
[libc++][CI] Improves buildbot runner. Adds documentation and shows a help message when running the script without arguments. Lands parts of D139545.
2022-12-22 19:47:54 +01:00
CXX The C++ compiler to use, this value is used by CMake. This
variable is optional.
[libc++][modules] Adds the C++23 std module. The patch is based on D144994. D151030 added the module definitions for the module std. This patch wires in the module and enables the basic testing. Some notable features are missing: - There is no test that libc++ can be fully imported as a module. - This lacks the parts for the std.compat module. - The module is not shipped with libc++. Implements parts of - P2465R3 Standard Library Modules std and std.compat Reviewed By: ldionne, aaronmondal, #libc Differential Revision: https://reviews.llvm.org/D151814
2023-02-28 20:29:26 +01:00
CMAKE The CMake binary to use. This variable is optional.
[libc++] Enforce formatting for already formatted and new files and ignore the formatting of tests It is quite confusing to newcomers that the formatting check gets mostly ignored. To fix that, enforce the formatting for new file and already formatted files, but ignore it for any files that aren't formatted already. We ignore the tests for now, since almost no test is formatted currently, and they are changed almost never. Reviewed By: ldionne, Mordante, #libc Spies: arichardson, fedor.sergeev, phosek, sstefan1, libcxx-commits, abrachet Differential Revision: https://reviews.llvm.org/D142180
2023-01-20 07:42:44 +01:00
CLANG_FORMAT The clang-format binary to use when generating the format
ignore list.
[libc++] Allow customizing a few paths when running build bots This allows reusing run-buildbot for downstream testing as well.
2020-11-05 19:02:32 -05:00
EOF
}
[libc++][CI] Improves buildbot runner. Adds documentation and shows a help message when running the script without arguments. Lands parts of D139545.
2022-12-22 19:47:54 +01:00
if [[ $# == 0 ]]; then
usage
exit 0
fi
[libc++] Allow customizing a few paths when running build bots This allows reusing run-buildbot for downstream testing as well.
2020-11-05 19:02:32 -05:00
while [[ $# -gt 0 ]]; do
case ${1} in
-h|--help)
usage
exit 0
;;
--llvm-root)
MONOREPO_ROOT="${2}"
shift; shift
;;
[libc++] Also allow customizing the build directory when running CI
2020-11-05 19:09:03 -05:00
--build-dir)
BUILD_DIR="${2}"
shift; shift
;;
[libc++] Allow customizing a few paths when running build bots This allows reusing run-buildbot for downstream testing as well.
2020-11-05 19:02:32 -05:00
*)
BUILDER="${1}"
shift
;;
esac
done
MONOREPO_ROOT="${MONOREPO_ROOT:="$(git rev-parse --show-toplevel)"}"
[libc++] Also allow customizing the build directory when running CI
2020-11-05 19:09:03 -05:00
BUILD_DIR="${BUILD_DIR:=${MONOREPO_ROOT}/build/${BUILDER}}"
[libc++] Fix typo in run-buildbot The installation directory was never meant to contain a brace.
2021-01-07 17:37:09 -05:00
INSTALL_DIR="${BUILD_DIR}/install"
[libc++] Initial support for pre-commit CI with Buildkite This commit adds basic files and scripts that are used for the Buildkite pre-commit CI setup. This was tested to mostly work on a fork of llvm-project, however some adjustments will have to be made as we complete the real setup.
2020-09-23 09:20:03 -04:00
[libc++] Use Xcode's CMake if it's present This resolves issues when the CMake in use on the host is too old to configure libc++ properly, but Xcode has a sufficiently recent version. It is technically possible for the reverse issue to happen, where the Xcode version would be too old and the user-installed version would be better, however in the context of our build bots, we use AppleClang on Apple platforms, and the CMake shipped with Xcode should work with the AppleClang shipped alongside that Xcode. Differential Revision: https://reviews.llvm.org/D102083
2021-05-07 13:14:57 -04:00
# If we can find Ninja/CMake provided by Xcode, use those since we know their
# version will generally work with the Clang shipped in Xcode (e.g. if Clang
# knows about -std=c++20, the CMake bundled in Xcode will probably know about
# that flag too).
[libc++][modules] Adds the C++23 std module. The patch is based on D144994. D151030 added the module definitions for the module std. This patch wires in the module and enables the basic testing. Some notable features are missing: - There is no test that libc++ can be fully imported as a module. - This lacks the parts for the std.compat module. - The module is not shipped with libc++. Implements parts of - P2465R3 Standard Library Modules std and std.compat Reviewed By: ldionne, aaronmondal, #libc Differential Revision: https://reviews.llvm.org/D151814
2023-02-28 20:29:26 +01:00
if xcrun --find ninja &>/dev/null; then
NINJA="$(xcrun --find ninja)"
elif which ninja &>/dev/null; then
# The current implementation of modules needs the absolute path to the ninja
# binary.
# TODO MODULES Is this still needed when CMake has libc++ module support?
NINJA="$(which ninja)"
else
NINJA="ninja"
fi
if [ -z "${CMAKE}" ]; then
if xcrun --find cmake &>/dev/null; then
CMAKE="$(xcrun --find cmake)"
else
CMAKE="cmake"
fi
fi
[libc++] Properly pick up the Ninja from Xcode in the CI script
2021-03-04 16:01:36 -05:00
[libc++] Add output groups to run-buildbot (#111739) This improves the CI output by providing collapsable sections for sub-parts of our build. This was originally opened as #75233. Co-authored-by: eric <eric@efcs.ca>
2024-10-11 09:29:47 -04:00
function step() {
endstep
set +x
if [[ ! -z ${GITHUB_ACTIONS+x} ]]; then
echo "::group::$1"
export IN_GROUP=1
else
echo "--- $1"
fi
set -x
}
function endstep() {
set +x
if [[ ! -z ${GITHUB_ACTIONS+x} ]] && [[ ! -z ${IN_GROUP+x} ]]; then
echo "::endgroup::"
unset IN_GROUP
fi
set -x
}
function error() {
echo "::error::$1"
}
[libc++] Allow customizing a few paths when running build bots This allows reusing run-buildbot for downstream testing as well.
2020-11-05 19:02:32 -05:00
function clean() {
rm -rf "${BUILD_DIR}"
}
[libcxx] [ci] Add a Windows CI configuration for a statically linked libc++ On Windows, static vs DLL linking affects details in quite a few cases, so it's good to have coverage for both cases. Testing with static linking also increases coverage for a number of cases and individual checks that have had to be waived for the DLL case, and allows testing libc++experimental, increasing the number of test cases actually executed by 180 (176 new tests from libc++experimental and 4 ones that are XFAIL windows-dll). Also drop the "generic-" prefix from these configuration names, as they're perhaps not what the "generic" prefix intended originally in the other generic-posix configurations. Differential Revision: https://reviews.llvm.org/D101565
2021-04-06 00:17:30 +03:00
function generate-cmake-base() {
[libc++] Add output groups to run-buildbot (#111739) This improves the CI output by providing collapsable sections for sub-parts of our build. This was originally opened as #75233. Co-authored-by: eric <eric@efcs.ca>
2024-10-11 09:29:47 -04:00
step "Generating CMake"
[libc++] Use Xcode's CMake if it's present This resolves issues when the CMake in use on the host is too old to configure libc++ properly, but Xcode has a sufficiently recent version. It is technically possible for the reverse issue to happen, where the Xcode version would be too old and the user-installed version would be better, however in the context of our build bots, we use AppleClang on Apple platforms, and the CMake shipped with Xcode should work with the AppleClang shipped alongside that Xcode. Differential Revision: https://reviews.llvm.org/D102083
2021-05-07 13:14:57 -04:00
${CMAKE} \
[runtimes] Use the new "runtimes" build by default and deprecate other builds This commit makes the new "runtimes" build (with <monorepo>/runtimes as the root of the CMake invocation) the default way of building libc++. The other supported way of building libc++ is the "bootstrapping" build, where `<monorepo>/llvm` is used as the root of the CMake invocation. All other ways of building libc++ are deprecated effective immediately. There should be no use-case for building libc++ that isn't supported by one of these two builds, and the two new builds work on all environments and are lightweight. They will also make it possible to greatly simplify the build infrastructure of the runtimes, which is currently way too convoluted. Differential Revision: https://reviews.llvm.org/D111356
2021-10-07 16:19:11 -04:00
-S "${MONOREPO_ROOT}/runtimes" \
[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 10:02:14 -04:00
-B "${BUILD_DIR}" \
[libc++] Properly pick up the Ninja from Xcode in the CI script
2021-03-04 16:01:36 -05:00
-GNinja -DCMAKE_MAKE_PROGRAM="${NINJA}" \
[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 10:02:14 -04:00
-DCMAKE_BUILD_TYPE=RelWithDebInfo \
-DCMAKE_INSTALL_PREFIX="${INSTALL_DIR}" \
[libcxx] [ci] Enable LIBCXX_ENABLE_WERROR where possible Only opt out from it in the few configs (GCC based) where there still are build warnings. Differential Revision: https://reviews.llvm.org/D119573
2022-02-10 13:08:24 +02:00
-DLIBCXX_ENABLE_WERROR=YES \
[libcxx] [ci] Enable -Werror for libcxxabi and libunwind too Differential Revision: https://reviews.llvm.org/D122800
2022-03-31 11:51:30 +03:00
-DLIBCXXABI_ENABLE_WERROR=YES \
-DLIBUNWIND_ENABLE_WERROR=YES \
Improve CI output. (#70236) There is currently a major problem with the CI output: The information you need to see never appears in the visible log. This is because our logs are very verbose, and list (A) every test as they run it, and (B) every unsupported tests. This can be thousands of lines. (A) was introduced by me when I disabled the PTY progress bar, which doesn't play nice with log files. That change was an improvement, but I have now disabled the PTY on the builders, so we can go back to passing `-s`. When `-s` is passed but no PTY is available, it prints a long friendly progress indicator. (B) is solved here by disabling the printing of unsupported tests at the end of the test suite. While it can be useful on occasion to audit the list of unsupported tests, it's far from a common operation. Instead people want to see the log of their failure. We should upload the xml results, so if auditing is needed, it can be done using that. Hopefully this change will make it so that the test failures appear in the actual log output
2023-10-25 18:10:29 -04:00
-DLLVM_LIT_ARGS="-sv --xunit-xml-output test-results.xml --timeout=1500 --time-tests" \
[libcxx] [ci] Add a Windows CI configuration for a statically linked libc++ On Windows, static vs DLL linking affects details in quite a few cases, so it's good to have coverage for both cases. Testing with static linking also increases coverage for a number of cases and individual checks that have had to be waived for the DLL case, and allows testing libc++experimental, increasing the number of test cases actually executed by 180 (176 new tests from libc++experimental and 4 ones that are XFAIL windows-dll). Also drop the "generic-" prefix from these configuration names, as they're perhaps not what the "generic" prefix intended originally in the other generic-posix configurations. Differential Revision: https://reviews.llvm.org/D101565
2021-04-06 00:17:30 +03:00
"${@}"
}
function generate-cmake() {
generate-cmake-base \
[runtimes] Use the new "runtimes" build by default and deprecate other builds This commit makes the new "runtimes" build (with <monorepo>/runtimes as the root of the CMake invocation) the default way of building libc++. The other supported way of building libc++ is the "bootstrapping" build, where `<monorepo>/llvm` is used as the root of the CMake invocation. All other ways of building libc++ are deprecated effective immediately. There should be no use-case for building libc++ that isn't supported by one of these two builds, and the two new builds work on all environments and are lightweight. They will also make it possible to greatly simplify the build infrastructure of the runtimes, which is currently way too convoluted. Differential Revision: https://reviews.llvm.org/D111356
2021-10-07 16:19:11 -04:00
-DLLVM_ENABLE_RUNTIMES="libcxx;libcxxabi;libunwind" \
[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 10:02:14 -04:00
-DLIBCXX_CXX_ABI=libcxxabi \
[libc++] Add a Buildkite job that tests back-deployment on Apple The current way we test this is pretty cheap, i.e. we download previously released macOS dylibs and run against that. Ideally, we would require a full host running the appropriate version of macOS, and we'd execute the tests using SSH on that host. But since we don't have such hosts available easily for now, this is better than nothing. At the same time, also fix some tests that were failing when back deploying. Differential Revision: https://reviews.llvm.org/D90869
2020-11-05 10:47:06 -05:00
"${@}"
}
[libcxx] [ci] Add a Windows CI configuration for a statically linked libc++ On Windows, static vs DLL linking affects details in quite a few cases, so it's good to have coverage for both cases. Testing with static linking also increases coverage for a number of cases and individual checks that have had to be waived for the DLL case, and allows testing libc++experimental, increasing the number of test cases actually executed by 180 (176 new tests from libc++experimental and 4 ones that are XFAIL windows-dll). Also drop the "generic-" prefix from these configuration names, as they're perhaps not what the "generic" prefix intended originally in the other generic-posix configurations. Differential Revision: https://reviews.llvm.org/D101565
2021-04-06 00:17:30 +03:00
function generate-cmake-libcxx-win() {
generate-cmake-base \
[runtimes] Use the new "runtimes" build by default and deprecate other builds This commit makes the new "runtimes" build (with <monorepo>/runtimes as the root of the CMake invocation) the default way of building libc++. The other supported way of building libc++ is the "bootstrapping" build, where `<monorepo>/llvm` is used as the root of the CMake invocation. All other ways of building libc++ are deprecated effective immediately. There should be no use-case for building libc++ that isn't supported by one of these two builds, and the two new builds work on all environments and are lightweight. They will also make it possible to greatly simplify the build infrastructure of the runtimes, which is currently way too convoluted. Differential Revision: https://reviews.llvm.org/D111356
2021-10-07 16:19:11 -04:00
-DLLVM_ENABLE_RUNTIMES="libcxx" \
[libcxx] [ci] Add a Windows CI configuration for a statically linked libc++ On Windows, static vs DLL linking affects details in quite a few cases, so it's good to have coverage for both cases. Testing with static linking also increases coverage for a number of cases and individual checks that have had to be waived for the DLL case, and allows testing libc++experimental, increasing the number of test cases actually executed by 180 (176 new tests from libc++experimental and 4 ones that are XFAIL windows-dll). Also drop the "generic-" prefix from these configuration names, as they're perhaps not what the "generic" prefix intended originally in the other generic-posix configurations. Differential Revision: https://reviews.llvm.org/D101565
2021-04-06 00:17:30 +03:00
-DCMAKE_C_COMPILER=clang-cl \
-DCMAKE_CXX_COMPILER=clang-cl \
"${@}"
}
[libc++][Android] Support libc++ testing on Android (#69274) I could probably break this commit into more pieces. --- This patch adds libc++ support for Android L (Android 5.0+) and up, tested using the Android team's current compiler, a recent version of the AOSP sysroot, and the x86[-64] Android Emulator. CMake and Lit Configuration: Add runtimes/cmake/android/Arch-${ARCH}.cmake files that configure CMake to cross-compile to Android without using CMake's built-in NDK support (which only works with an actual packaged NDK). Add libcxx/cmake/caches/AndroidNDK.cmake that builds and tests libc++ (and libc++abi) for Android. This file configures libc++ to match what the NDK distributes, e.g.: - libc++_shared.so (includes libc++abi objects, there is no libc++abi.so). libunwind is linked statically but not exported. - libc++_static.a (does not include libc++abi) and libc++abi.a - `std::__ndk1` namespace - All the libraries are built with `__ANDROID_API__=21`, even when they are linked to something targeting a higher API level. (However, when the Android LLVM team builds these components, they do not use these CMake cache files. Instead they use Python scripts to configure the builds. See https://android.googlesource.com/toolchain/llvm_android/.) Add llvm-libc++[abi].android-ndk.cfg.in files that test the Android NDK's libc++_shared.so. These files can target old or new Android devices. The Android LLVM team uses these test files to test libc++ for both arm/arm64 and x86/x86_64 architectures. The Android testing mode works by setting %{executor} to adb_run.py, which uses `adb push` and `adb shell` to run tests remotely. adb_run.py always runs tests as the "shell" user even on an old emulator where "adb unroot" doesn't work. The script has workarounds for old Android devices. The script uses a Unix domain socket on the host (--job-limit-socket) to restrict concurrent adb invocations. Compiling the tests is a major part of libc++ testing run-time, so it's desirable to exploit all the host cores without overburdening the test devices, which can have far fewer cores. BuildKite CI: Add a builder to run-buildbot, `android-ndk-*`, that uses Android Clang and an Android sysroot to build libc++, then starts an Android emulator container to run tests. Run the emulator and an adb server in a separate Docker container (libcxx-ci-android-emulator), and create a separate Docker image for each emulator OS system image. Set ADB_SERVER_SOCKET to connect to the container's adb server. Running the only adb server inside the container makes cleanup more reliable between test runs, e.g. the adb client doesn't create a `~/.android` directory and the adb server can be restarted along with the emulator using docker stop/run. (N.B. The emulator insists on connecting to an adb server and will start one itself if it can't connect to one.) The suffix to the android-ndk-* job is a label that concisely specifies an Android SDK emulator image. e.g.: - "system-images;android-21;default;x86" ==> 21-def-x86 - "system-images;android-33;google_apis;x86_64" ==> 33-goog-x86_64 Fixes: https://github.com/llvm/llvm-project/issues/69270 Differential Revision: https://reviews.llvm.org/D139147
2023-10-19 13:58:30 -07:00
function generate-cmake-android() {
generate-cmake-base \
-DLLVM_ENABLE_RUNTIMES="libcxx;libcxxabi" \
-DLIBCXX_CXX_ABI=libcxxabi \
"${@}"
}
[runtimes][ci] Run the tests for libunwind in the CI We should arguably have always been doing that. The state of libunwind is quite sad, so this commit adds several XFAILs to make the CI pass. We need to investigate why so many tests are not passing in some configurations, but I'll defer that to folks who actually work on libunwind for lack of bandwidth. Differential Revision: https://reviews.llvm.org/D110872
2021-09-30 15:11:48 -04:00
function check-runtimes() {
[libc++] Add output groups to run-buildbot (#111739) This improves the CI output by providing collapsable sections for sub-parts of our build. This was originally opened as #75233. Co-authored-by: eric <eric@efcs.ca>
2024-10-11 09:29:47 -04:00
step "Building libc++ test dependencies"
${NINJA} -vC "${BUILD_DIR}" cxx-test-depends
step "Running the libc++ tests"
[libc++] Run ninja with --verbose This makes it easier to see what exact build commands are used. Differential Revision: https://reviews.llvm.org/D98992
2021-03-19 16:26:15 -07:00
${NINJA} -vC "${BUILD_DIR}" check-cxx
[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 10:02:14 -04:00
[libc++] Add output groups to run-buildbot (#111739) This improves the CI output by providing collapsable sections for sub-parts of our build. This was originally opened as #75233. Co-authored-by: eric <eric@efcs.ca>
2024-10-11 09:29:47 -04:00
step "Running the libc++abi tests"
[libc++] Run ninja with --verbose This makes it easier to see what exact build commands are used. Differential Revision: https://reviews.llvm.org/D98992
2021-03-19 16:26:15 -07:00
${NINJA} -vC "${BUILD_DIR}" check-cxxabi
[runtimes][ci] Run the tests for libunwind in the CI We should arguably have always been doing that. The state of libunwind is quite sad, so this commit adds several XFAILs to make the CI pass. We need to investigate why so many tests are not passing in some configurations, but I'll defer that to folks who actually work on libunwind for lack of bandwidth. Differential Revision: https://reviews.llvm.org/D110872
2021-09-30 15:11:48 -04:00
[libc++] Add output groups to run-buildbot (#111739) This improves the CI output by providing collapsable sections for sub-parts of our build. This was originally opened as #75233. Co-authored-by: eric <eric@efcs.ca>
2024-10-11 09:29:47 -04:00
step "Running the libunwind tests"
[runtimes][ci] Run the tests for libunwind in the CI We should arguably have always been doing that. The state of libunwind is quite sad, so this commit adds several XFAILs to make the CI pass. We need to investigate why so many tests are not passing in some configurations, but I'll defer that to folks who actually work on libunwind for lack of bandwidth. Differential Revision: https://reviews.llvm.org/D110872
2021-09-30 15:11:48 -04:00
${NINJA} -vC "${BUILD_DIR}" check-unwind
[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 10:02:14 -04:00
}
[libc++] Formalize what configurations are covered by the ABI lists By encoding ABI-affecting properties in the name of the ABI list, it makes it clear when an ABI list test should or should not be available, and what results we should expect. Note that we clearly don't encode all ABI-affecting parameters in the name right now -- I just ported over what we supported in the code that was there previously. As we encounter configurations that we wish to support but produce different ABI lists, we can add those to the ABI identifier and start supporting them. This commit also starts checking the ABI list in the CI jobs that run a supported configuration. Eventually, all configurations should have a generated ABI list and the test should even run implicitly as part of the Lit test suite. Differential Revision: https://reviews.llvm.org/D92194
2020-11-26 15:00:42 -05:00
# TODO: The goal is to test this against all configurations. We should also move
# this to the Lit test suite instead of being a separate CMake target.
function check-abi-list() {
[libc++] Add output groups to run-buildbot (#111739) This improves the CI output by providing collapsable sections for sub-parts of our build. This was originally opened as #75233. Co-authored-by: eric <eric@efcs.ca>
2024-10-11 09:29:47 -04:00
step "Running the libc++ ABI list test"
[libc++] Run ninja with --verbose This makes it easier to see what exact build commands are used. Differential Revision: https://reviews.llvm.org/D98992
2021-03-19 16:26:15 -07:00
${NINJA} -vC "${BUILD_DIR}" check-cxx-abilist || (
[libc++] Add output groups to run-buildbot (#111739) This improves the CI output by providing collapsable sections for sub-parts of our build. This was originally opened as #75233. Co-authored-by: eric <eric@efcs.ca>
2024-10-11 09:29:47 -04:00
error "Generating the libc++ ABI list after failed check"
[libc++] Run ninja with --verbose This makes it easier to see what exact build commands are used. Differential Revision: https://reviews.llvm.org/D98992
2021-03-19 16:26:15 -07:00
${NINJA} -vC "${BUILD_DIR}" generate-cxx-abilist
[libc++] [P0482] [C++20] Implement missing bits for codecvt and codecvt_byname. Add codecvt*<char16_t, char8_t> and codecvt*<char32_t, char8_t>. Deprecate codecvt<char(16|32)_t, char>. Enable disabled tests. Update _LIBCPP_STD_VER to use 20 for C++20. Add _LIBCPP_DEPRECATED_IN_CXX20 macro. Reviewed By: ldionne, #libc, #libc_abi Differential Revision: https://reviews.llvm.org/D91517
2020-12-02 08:57:02 +01:00
false
)
[libc++] Formalize what configurations are covered by the ABI lists By encoding ABI-affecting properties in the name of the ABI list, it makes it clear when an ABI list test should or should not be available, and what results we should expect. Note that we clearly don't encode all ABI-affecting parameters in the name right now -- I just ported over what we supported in the code that was there previously. As we encounter configurations that we wish to support but produce different ABI lists, we can add those to the ABI identifier and start supporting them. This commit also starts checking the ABI list in the CI jobs that run a supported configuration. Eventually, all configurations should have a generated ABI list and the test should even run implicitly as part of the Lit test suite. Differential Revision: https://reviews.llvm.org/D92194
2020-11-26 15:00:42 -05:00
}
[libc++] Add a picolibc test configuration with exceptions enabled (#75462)
2023-12-18 16:25:50 +01:00
function test-armv7m-picolibc() {
clean
# To make it easier to get this builder up and running, build picolibc
# from scratch. Anecdotally, the build-picolibc script takes about 16 seconds.
# This could be optimised by building picolibc into the Docker container.
[libc++] Add output groups to run-buildbot (#111739) This improves the CI output by providing collapsable sections for sub-parts of our build. This was originally opened as #75233. Co-authored-by: eric <eric@efcs.ca>
2024-10-11 09:29:47 -04:00
step "Building picolibc from source"
[libc++] Add a picolibc test configuration with exceptions enabled (#75462)
2023-12-18 16:25:50 +01:00
${MONOREPO_ROOT}/libcxx/utils/ci/build-picolibc.sh \
--build-dir "${BUILD_DIR}" \
--install-dir "${INSTALL_DIR}" \
--target armv7m-none-eabi
[libc++] Add output groups to run-buildbot (#111739) This improves the CI output by providing collapsable sections for sub-parts of our build. This was originally opened as #75233. Co-authored-by: eric <eric@efcs.ca>
2024-10-11 09:29:47 -04:00
step "Generating CMake for compiler-rt"
[libc++] Add a picolibc test configuration with exceptions enabled (#75462)
2023-12-18 16:25:50 +01:00
flags="--sysroot=${INSTALL_DIR}"
${CMAKE} \
-S "${MONOREPO_ROOT}/compiler-rt" \
-B "${BUILD_DIR}/compiler-rt" \
-GNinja -DCMAKE_MAKE_PROGRAM="${NINJA}" \
-DCMAKE_BUILD_TYPE=RelWithDebInfo \
-DCMAKE_INSTALL_PREFIX="${INSTALL_DIR}" \
-DCMAKE_C_FLAGS="${flags}" \
-DCMAKE_CXX_FLAGS="${flags}" \
-DLLVM_ENABLE_PER_TARGET_RUNTIME_DIR=ON \
"${@}"
[libc++] Add output groups to run-buildbot (#111739) This improves the CI output by providing collapsable sections for sub-parts of our build. This was originally opened as #75233. Co-authored-by: eric <eric@efcs.ca>
2024-10-11 09:29:47 -04:00
step "Generating CMake for libc++"
[libc++] Add a picolibc test configuration with exceptions enabled (#75462)
2023-12-18 16:25:50 +01:00
generate-cmake \
-DLIBCXX_TEST_CONFIG="armv7m-picolibc-libc++.cfg.in" \
-DLIBCXXABI_TEST_CONFIG="armv7m-picolibc-libc++abi.cfg.in" \
-DLIBUNWIND_TEST_CONFIG="armv7m-picolibc-libunwind.cfg.in" \
-DCMAKE_C_FLAGS="${flags}" \
-DCMAKE_CXX_FLAGS="${flags}" \
"${@}"
[libc++] Add output groups to run-buildbot (#111739) This improves the CI output by providing collapsable sections for sub-parts of our build. This was originally opened as #75233. Co-authored-by: eric <eric@efcs.ca>
2024-10-11 09:29:47 -04:00
step "Installing compiler-rt"
[libc++] Add a picolibc test configuration with exceptions enabled (#75462)
2023-12-18 16:25:50 +01:00
${NINJA} -vC "${BUILD_DIR}/compiler-rt" install
[libcxx][ci] In picolib build, ask clang for the normalised triple (#90722) This is needed for a workaround to make sure the link later succeeds. I don't know the reason for that but it is definitely needed. https://github.com/llvm/llvm-project/pull/89234 will/wants to correct the triple normalisation for -none- and this means that clang prior to 19, and clang 19 and above will have different answers and therefore different library paths. I don't want to bootstrap a clang just for libcxx CI, or require that anyone building for Arm do the same, so ask the compiler what the triple should be. This will be compatible with 17 and 19 when we do update to that version. I'm assuming $CC is what anyone locally would set to override the compiler, and `cc` is the binary name in our CI containers. It's not perfect but it should cover most use cases.
2024-05-01 15:10:01 +01:00
# Prior to clang 19, armv7m-none-eabi normalised to armv7m-none-unknown-eabi.
# clang 19 changed this to armv7m-unknown-none-eabi. So for as long as 18.x
# is supported, we have to ask clang what the triple will be.
NORMALISED_TARGET_TRIPLE=$(${CC-cc} --target=armv7m-none-eabi -print-target-triple)
# Without this step linking fails later in the build.
mv "${BUILD_DIR}/install/lib/${NORMALISED_TARGET_TRIPLE}"/* "${BUILD_DIR}/install/lib"
[libc++] Add a picolibc test configuration with exceptions enabled (#75462)
2023-12-18 16:25:50 +01:00
check-runtimes
}
[libc++] Print the CMake version before generating CMake
2021-04-01 13:40:04 -04:00
# Print the version of a few tools to aid diagnostics in some cases
[libc++] Add output groups to run-buildbot (#111739) This improves the CI output by providing collapsable sections for sub-parts of our build. This was originally opened as #75233. Co-authored-by: eric <eric@efcs.ca>
2024-10-11 09:29:47 -04:00
step "Diagnose tools in use"
[libc++] Use Xcode's CMake if it's present This resolves issues when the CMake in use on the host is too old to configure libc++ properly, but Xcode has a sufficiently recent version. It is technically possible for the reverse issue to happen, where the Xcode version would be too old and the user-installed version would be better, however in the context of our build bots, we use AppleClang on Apple platforms, and the CMake shipped with Xcode should work with the AppleClang shipped alongside that Xcode. Differential Revision: https://reviews.llvm.org/D102083
2021-05-07 13:14:57 -04:00
${CMAKE} --version
[libc++] Print the CMake version before generating CMake
2021-04-01 13:40:04 -04:00
${NINJA} --version
[libc++] Shows the detailed compiler version info. The libc++ pre-commit CI uses Clang nightly builds. Currently it's not possible to determine the exact version used since CMake doesn't show this information by default. Instead use the --version flag to get this information. Reviewed By: #libc, ldionne Differential Revision: https://reviews.llvm.org/D133122
2022-09-01 18:38:03 +02:00
if [ ! -z "${CXX}" ]; then ${CXX} --version; fi
[libc++] Initial support for pre-commit CI with Buildkite This commit adds basic files and scripts that are used for the Buildkite pre-commit CI setup. This was tested to mostly work on a fork of llvm-project, however some adjustments will have to be made as we complete the real setup.
2020-09-23 09:20:03 -04:00
case "${BUILDER}" in
[libc++] [CI] Validate the output of the generated scripts. This adds a CI job validating that the output of utils/generate_feature_test_macro_components.py, libcxx/utils/generate_header_inclusion_tests.py, and utils/generate_header_tests.py are up to date. The validation method has been copied from the Format job. Differential Revision: https://reviews.llvm.org/D99862
2021-04-04 20:11:48 +02:00
check-generated-output)
[libc++][CI] Fix check-generated-output. Before the script detected non-ASCII characters but let them pass. This fixes the issue. I had a way to solve the issue, during review @Quuxplusone suggested a better alternative. The patch has been changed to use this alternative. Intended failed builds: - Not updated generated files https://buildkite.com/llvm-project/libcxx-ci/builds/2822 - Not updated generated files and non-ASCII usage https://buildkite.com/llvm-project/libcxx-ci/builds/2835 - Non-ASCII usage https://buildkite.com/llvm-project/libcxx-ci/builds/2836 Reviewed By: #libc, Quuxplusone, curdeius Differential Revision: https://reviews.llvm.org/D101303
2021-04-28 19:13:52 +02:00
# `! foo` doesn't work properly with `set -e`, use `! foo || false` instead.
# https://stackoverflow.com/questions/57681955/set-e-does-not-respect-logical-not
[libc++] [CI] Validate the output of the generated scripts. This adds a CI job validating that the output of utils/generate_feature_test_macro_components.py, libcxx/utils/generate_header_inclusion_tests.py, and utils/generate_header_tests.py are up to date. The validation method has been copied from the Format job. Differential Revision: https://reviews.llvm.org/D99862
2021-04-04 20:11:48 +02:00
clean
[libc++] Add a CMake target to re-generate files and revamp CONTRIBUTING.rst As we automate more and more things in the library, it becomes useful for contributors to have a single target for running all the automation as part of their workflow. This commit adds a new `libcxx-generate-files` target that should re-generate all the auto-generated files in the library. As a fly-by, I also revamped the documentation on Contributing to account for this new target and present it as a bullet list of things to check before committing. I also added a few things that are often overlooked to that list, such as updating the synopsis and the status files. Differential Revision: https://reviews.llvm.org/D106067
2021-07-15 10:19:39 -04:00
generate-cmake
# Reject patches that forgot to re-run the generator scripts.
[libc++] Add output groups to run-buildbot (#111739) This improves the CI output by providing collapsable sections for sub-parts of our build. This was originally opened as #75233. Co-authored-by: eric <eric@efcs.ca>
2024-10-11 09:29:47 -04:00
step "Making sure the generator scripts were run"
set +x # Printing all the commands below just creates extremely confusing output
[libc++] Add a CMake target to re-generate files and revamp CONTRIBUTING.rst As we automate more and more things in the library, it becomes useful for contributors to have a single target for running all the automation as part of their workflow. This commit adds a new `libcxx-generate-files` target that should re-generate all the auto-generated files in the library. As a fly-by, I also revamped the documentation on Contributing to account for this new target and present it as a bullet list of things to check before committing. I also added a few things that are often overlooked to that list, such as updating the synopsis and the status files. Differential Revision: https://reviews.llvm.org/D106067
2021-07-15 10:19:39 -04:00
${NINJA} -vC "${BUILD_DIR}" libcxx-generate-files
[libc++] [CI] Validate the output of the generated scripts. This adds a CI job validating that the output of utils/generate_feature_test_macro_components.py, libcxx/utils/generate_header_inclusion_tests.py, and utils/generate_header_tests.py are up to date. The validation method has been copied from the Format job. Differential Revision: https://reviews.llvm.org/D99862
2021-04-04 20:11:48 +02:00
git diff | tee ${BUILD_DIR}/generated_output.patch
[libc++][ci] Detect not committed generated files. The Generated output CI job only tests for modified files. This job should also fail the generated output contains new files. It would be possible to test modified and untracked files in one execution of `git ls-files`. However the diff is stored as an artifact so the execution of `git diff` would still be required. Discussion: Would it be better to do `git ls-files -om` and remove the excution of `! grep -q '^--- a' ${BUILD_DIR}/generated_output.patch || false` ? (Obviously then the name `generated_output.untracked` should change to something like `generated_output.status`) Reviewed By: #libc, ldionne Differential Revision: https://reviews.llvm.org/D106534
2021-07-22 11:17:53 +02:00
git ls-files -o --exclude-standard | tee ${BUILD_DIR}/generated_output.status
[libc++][CI] Fix check-generated-output. Before the script detected non-ASCII characters but let them pass. This fixes the issue. I had a way to solve the issue, during review @Quuxplusone suggested a better alternative. The patch has been changed to use this alternative. Intended failed builds: - Not updated generated files https://buildkite.com/llvm-project/libcxx-ci/builds/2822 - Not updated generated files and non-ASCII usage https://buildkite.com/llvm-project/libcxx-ci/builds/2835 - Non-ASCII usage https://buildkite.com/llvm-project/libcxx-ci/builds/2836 Reviewed By: #libc, Quuxplusone, curdeius Differential Revision: https://reviews.llvm.org/D101303
2021-04-28 19:13:52 +02:00
! grep -q '^--- a' ${BUILD_DIR}/generated_output.patch || false
[libc++][ci] Detect not committed generated files. The Generated output CI job only tests for modified files. This job should also fail the generated output contains new files. It would be possible to test modified and untracked files in one execution of `git ls-files`. However the diff is stored as an artifact so the execution of `git diff` would still be required. Discussion: Would it be better to do `git ls-files -om` and remove the excution of `! grep -q '^--- a' ${BUILD_DIR}/generated_output.patch || false` ? (Obviously then the name `generated_output.untracked` should change to something like `generated_output.status`) Reviewed By: #libc, ldionne Differential Revision: https://reviews.llvm.org/D106534
2021-07-22 11:17:53 +02:00
if [ -s ${BUILD_DIR}/generated_output.status ]; then
echo "It looks like not all the generator scripts were run,"
echo "did you forget to build the libcxx-generate-files target?"
echo "Did you add all new files it generated?"
false
fi
[libc++] Add a CMake target to re-generate files and revamp CONTRIBUTING.rst As we automate more and more things in the library, it becomes useful for contributors to have a single target for running all the automation as part of their workflow. This commit adds a new `libcxx-generate-files` target that should re-generate all the auto-generated files in the library. As a fly-by, I also revamped the documentation on Contributing to account for this new target and present it as a bullet list of things to check before committing. I also added a few things that are often overlooked to that list, such as updating the synopsis and the status files. Differential Revision: https://reviews.llvm.org/D106067
2021-07-15 10:19:39 -04:00
[libc++] Add output groups to run-buildbot (#111739) This improves the CI output by providing collapsable sections for sub-parts of our build. This was originally opened as #75233. Co-authored-by: eric <eric@efcs.ca>
2024-10-11 09:29:47 -04:00
# This depends on LC_COLLATE set at the top of this script.
step "Reject patches that introduce non-ASCII characters or hard tabs."
[libc++] Remove nonexistent directory from check-generated-output (#111746) The libcxx/benchmarks directory was moved to libcxx/test/benchmarks, which is already checked by that grep command.
2024-10-10 07:57:45 -04:00
! grep -rn '[^ -~]' libcxx/include libcxx/src libcxx/test \
[libc++] Extend check for non-ASCII characters to src/, test/ and benchmarks/ Differential Revision: https://reviews.llvm.org/D132180
2022-08-18 17:41:13 -04:00
--exclude '*.dat' \
[libc++][print] Adds stdout functions. Implements parts of - P2093R14 Formatted output - P2539R4 Should the output of std::print to a terminal be synchronized with the underlying stream? Depends on D150044 Reviewed By: #libc, ldionne Differential Revision: https://reviews.llvm.org/D155262
2023-07-12 08:20:26 +02:00
--exclude '*unicode*.cpp' \
--exclude '*print*.sh.cpp' \
[libc++][format] Implements string escaping. Implements parts of - P2286R8 Formatting Ranges Reviewed By: #libc, tahonermann Differential Revision: https://reviews.llvm.org/D134036
2022-05-05 08:03:58 +02:00
--exclude 'escaped_output.*.pass.cpp' \
[libc++][chrono] Implements formatter day. This implements the enabled specializaton template<class charT> struct formatter<chrono::day, charT>; and template<class charT, class traits> basic_ostream<charT, traits>& operator<<(basic_ostream<charT, traits>& os, const day& d); Implements: - LWG 3241 chrono-spec grammar ambiguity in §[time.format] Partially implements: - P1361 Integration of chrono with text formatting Reviewed By: #libc, ldionne Differential Revision: https://reviews.llvm.org/D128577
2022-03-20 13:40:02 +01:00
--exclude 'format_tests.h' \
[libc++][format] Adds formatter for tuple and pair Implements parts of - P2286R8 Formatting Ranges Reviewed By: ldionne, #libc Differential Revision: https://reviews.llvm.org/D136775
2022-05-05 18:57:32 +02:00
--exclude 'format.functions.tests.h' \
[libc++][chrono] Implements formatter year. Partially implements: - P1361 Integration of chrono with text formatting Reviewed By: ldionne, #libc Differential Revision: https://reviews.llvm.org/D133663
2022-03-20 13:40:02 +01:00
--exclude 'formatter.*.pass.cpp' \
[libc++] Extend check for non-ASCII characters to src/, test/ and benchmarks/ Differential Revision: https://reviews.llvm.org/D132180
2022-08-18 17:41:13 -04:00
--exclude 'grep.pass.cpp' \
--exclude 'locale-specific_form.pass.cpp' \
[libc++][chrono] Implements formatter month. Partially implements: - P1361 Integration of chrono with text formatting Reviewed By: ldionne, #libc Differential Revision: https://reviews.llvm.org/D134138
2022-03-20 13:40:02 +01:00
--exclude 'ostream.pass.cpp' \
[libc++][format] Adds a UTF transcoder. This is a preparation for P2093R14 Formatted output When the output of print is to the terminal it needs to use the native API. This means transcoding UTF-8 to UTF-16 on Windows. The encoder's interface is modeled after P2728 Unicode in the Library, Part 1: UTF Transcoding But only the required part for P2093R14 is implemented. On Windows wchar_t is 16 bits, in order to test on platforms where wchar_t is 32 bits the transcoder has support for char16_t. It also adds and UTF-8 to UTF-32 encoder which is useful for other tests. Note it is possible to use <codecvt> for transcoding, but that header is deprecated. So rather write new code that is not deprecated; the hard part, decoding, has already been done. The <codecvt> header also requires locale support while the new code works without including <locale>. Note the current transcoder implementation can be optimized since it basically does UTF-8 -> UTF-32 -> UTF-16. The first goal is to have a working implementation. Since it's not part of the ABI it's possible to do the optimization later. Depends on D149672 Reviewed By: ldionne, tahonermann, #libc Differential Revision: https://reviews.llvm.org/D150031
2023-04-21 08:09:06 +02:00
--exclude 'transcoding.pass.cpp' \
[libc++] Introduce a setting to remove fstream from the library This allows porting the library to platforms that are able to support <iostream> but that do not have a notion of a filesystem, and where it hence doesn't make sense to support std::fstream (and never will). Also, remove reliance on <fstream> in various tests that didn't actually need it. Differential Revision: https://reviews.llvm.org/D138327
2022-11-18 15:01:33 -05:00
--exclude 'underflow.pass.cpp' \
[libc++][chrono] Implements formatter day. This implements the enabled specializaton template<class charT> struct formatter<chrono::day, charT>; and template<class charT, class traits> basic_ostream<charT, traits>& operator<<(basic_ostream<charT, traits>& os, const day& d); Implements: - LWG 3241 chrono-spec grammar ambiguity in §[time.format] Partially implements: - P1361 Integration of chrono with text formatting Reviewed By: #libc, ldionne Differential Revision: https://reviews.llvm.org/D128577
2022-03-20 13:40:02 +01:00
|| false
[libc++] [CI] Validate the output of the generated scripts. This adds a CI job validating that the output of utils/generate_feature_test_macro_components.py, libcxx/utils/generate_header_inclusion_tests.py, and utils/generate_header_tests.py are up to date. The validation method has been copied from the Format job. Differential Revision: https://reviews.llvm.org/D99862
2021-04-04 20:11:48 +02:00
;;
[libc++][NFC] Refactor run-buildbot to make it closer to our buildkite pipeline Differential Revision: https://reviews.llvm.org/D138380
2022-11-18 16:17:10 -05:00
#
# Various Standard modes
#
[libc++][ci] Add a job to run the vanilla configuration on Apple Previously, we'd only have jobs testing the Apple cache on Apple platforms, but libc++ should also work out-of-the-box.
2020-10-01 13:55:39 -04:00
generic-cxx03)
[libc++] Allow customizing a few paths when running build bots This allows reusing run-buildbot for downstream testing as well.
2020-11-05 19:02:32 -05:00
clean
[libc++] Enable clang-tidy from the buildkite pipeline instead of hard-coding it in run-buildbot Reviewed By: ldionne, #libc, Mordante, emaste Spies: emaste, Mordante, libcxx-commits, arichardson Differential Revision: https://reviews.llvm.org/D141294
2023-01-09 17:45:45 +01:00
generate-cmake -C "${MONOREPO_ROOT}/libcxx/cmake/caches/Generic-cxx03.cmake"
[runtimes][ci] Run the tests for libunwind in the CI We should arguably have always been doing that. The state of libunwind is quite sad, so this commit adds several XFAILs to make the CI pass. We need to investigate why so many tests are not passing in some configurations, but I'll defer that to folks who actually work on libunwind for lack of bandwidth. Differential Revision: https://reviews.llvm.org/D110872
2021-09-30 15:11:48 -04:00
check-runtimes
[libc++] Formalize what configurations are covered by the ABI lists By encoding ABI-affecting properties in the name of the ABI list, it makes it clear when an ABI list test should or should not be available, and what results we should expect. Note that we clearly don't encode all ABI-affecting parameters in the name right now -- I just ported over what we supported in the code that was there previously. As we encounter configurations that we wish to support but produce different ABI lists, we can add those to the ABI identifier and start supporting them. This commit also starts checking the ABI list in the CI jobs that run a supported configuration. Eventually, all configurations should have a generated ABI list and the test should even run implicitly as part of the Lit test suite. Differential Revision: https://reviews.llvm.org/D92194
2020-11-26 15:00:42 -05:00
check-abi-list
[libc++] Initial support for pre-commit CI with Buildkite This commit adds basic files and scripts that are used for the Buildkite pre-commit CI setup. This was tested to mostly work on a fork of llvm-project, however some adjustments will have to be made as we complete the real setup.
2020-09-23 09:20:03 -04:00
;;
[libc++][ci] Add a job to run the vanilla configuration on Apple Previously, we'd only have jobs testing the Apple cache on Apple platforms, but libc++ should also work out-of-the-box.
2020-10-01 13:55:39 -04:00
generic-cxx11)
[libc++] Allow customizing a few paths when running build bots This allows reusing run-buildbot for downstream testing as well.
2020-11-05 19:02:32 -05:00
clean
[libc++] Enable clang-tidy from the buildkite pipeline instead of hard-coding it in run-buildbot Reviewed By: ldionne, #libc, Mordante, emaste Spies: emaste, Mordante, libcxx-commits, arichardson Differential Revision: https://reviews.llvm.org/D141294
2023-01-09 17:45:45 +01:00
generate-cmake -C "${MONOREPO_ROOT}/libcxx/cmake/caches/Generic-cxx11.cmake"
[runtimes][ci] Run the tests for libunwind in the CI We should arguably have always been doing that. The state of libunwind is quite sad, so this commit adds several XFAILs to make the CI pass. We need to investigate why so many tests are not passing in some configurations, but I'll defer that to folks who actually work on libunwind for lack of bandwidth. Differential Revision: https://reviews.llvm.org/D110872
2021-09-30 15:11:48 -04:00
check-runtimes
[libc++] Formalize what configurations are covered by the ABI lists By encoding ABI-affecting properties in the name of the ABI list, it makes it clear when an ABI list test should or should not be available, and what results we should expect. Note that we clearly don't encode all ABI-affecting parameters in the name right now -- I just ported over what we supported in the code that was there previously. As we encounter configurations that we wish to support but produce different ABI lists, we can add those to the ABI identifier and start supporting them. This commit also starts checking the ABI list in the CI jobs that run a supported configuration. Eventually, all configurations should have a generated ABI list and the test should even run implicitly as part of the Lit test suite. Differential Revision: https://reviews.llvm.org/D92194
2020-11-26 15:00:42 -05:00
check-abi-list
[libc++] Initial support for pre-commit CI with Buildkite This commit adds basic files and scripts that are used for the Buildkite pre-commit CI setup. This was tested to mostly work on a fork of llvm-project, however some adjustments will have to be made as we complete the real setup.
2020-09-23 09:20:03 -04:00
;;
[libc++][ci] Add a job to run the vanilla configuration on Apple Previously, we'd only have jobs testing the Apple cache on Apple platforms, but libc++ should also work out-of-the-box.
2020-10-01 13:55:39 -04:00
generic-cxx14)
[libc++] Allow customizing a few paths when running build bots This allows reusing run-buildbot for downstream testing as well.
2020-11-05 19:02:32 -05:00
clean
[libc++] Enable clang-tidy from the buildkite pipeline instead of hard-coding it in run-buildbot Reviewed By: ldionne, #libc, Mordante, emaste Spies: emaste, Mordante, libcxx-commits, arichardson Differential Revision: https://reviews.llvm.org/D141294
2023-01-09 17:45:45 +01:00
generate-cmake -C "${MONOREPO_ROOT}/libcxx/cmake/caches/Generic-cxx14.cmake"
[runtimes][ci] Run the tests for libunwind in the CI We should arguably have always been doing that. The state of libunwind is quite sad, so this commit adds several XFAILs to make the CI pass. We need to investigate why so many tests are not passing in some configurations, but I'll defer that to folks who actually work on libunwind for lack of bandwidth. Differential Revision: https://reviews.llvm.org/D110872
2021-09-30 15:11:48 -04:00
check-runtimes
[libc++] Formalize what configurations are covered by the ABI lists By encoding ABI-affecting properties in the name of the ABI list, it makes it clear when an ABI list test should or should not be available, and what results we should expect. Note that we clearly don't encode all ABI-affecting parameters in the name right now -- I just ported over what we supported in the code that was there previously. As we encounter configurations that we wish to support but produce different ABI lists, we can add those to the ABI identifier and start supporting them. This commit also starts checking the ABI list in the CI jobs that run a supported configuration. Eventually, all configurations should have a generated ABI list and the test should even run implicitly as part of the Lit test suite. Differential Revision: https://reviews.llvm.org/D92194
2020-11-26 15:00:42 -05:00
check-abi-list
[libc++] Initial support for pre-commit CI with Buildkite This commit adds basic files and scripts that are used for the Buildkite pre-commit CI setup. This was tested to mostly work on a fork of llvm-project, however some adjustments will have to be made as we complete the real setup.
2020-09-23 09:20:03 -04:00
;;
[libc++][ci] Add a job to run the vanilla configuration on Apple Previously, we'd only have jobs testing the Apple cache on Apple platforms, but libc++ should also work out-of-the-box.
2020-10-01 13:55:39 -04:00
generic-cxx17)
[libc++] Allow customizing a few paths when running build bots This allows reusing run-buildbot for downstream testing as well.
2020-11-05 19:02:32 -05:00
clean
[libc++] Enable clang-tidy from the buildkite pipeline instead of hard-coding it in run-buildbot Reviewed By: ldionne, #libc, Mordante, emaste Spies: emaste, Mordante, libcxx-commits, arichardson Differential Revision: https://reviews.llvm.org/D141294
2023-01-09 17:45:45 +01:00
generate-cmake -C "${MONOREPO_ROOT}/libcxx/cmake/caches/Generic-cxx17.cmake"
[runtimes][ci] Run the tests for libunwind in the CI We should arguably have always been doing that. The state of libunwind is quite sad, so this commit adds several XFAILs to make the CI pass. We need to investigate why so many tests are not passing in some configurations, but I'll defer that to folks who actually work on libunwind for lack of bandwidth. Differential Revision: https://reviews.llvm.org/D110872
2021-09-30 15:11:48 -04:00
check-runtimes
[libc++] Formalize what configurations are covered by the ABI lists By encoding ABI-affecting properties in the name of the ABI list, it makes it clear when an ABI list test should or should not be available, and what results we should expect. Note that we clearly don't encode all ABI-affecting parameters in the name right now -- I just ported over what we supported in the code that was there previously. As we encounter configurations that we wish to support but produce different ABI lists, we can add those to the ABI identifier and start supporting them. This commit also starts checking the ABI list in the CI jobs that run a supported configuration. Eventually, all configurations should have a generated ABI list and the test should even run implicitly as part of the Lit test suite. Differential Revision: https://reviews.llvm.org/D92194
2020-11-26 15:00:42 -05:00
check-abi-list
[libc++] Initial support for pre-commit CI with Buildkite This commit adds basic files and scripts that are used for the Buildkite pre-commit CI setup. This was tested to mostly work on a fork of llvm-project, however some adjustments will have to be made as we complete the real setup.
2020-09-23 09:20:03 -04:00
;;
[libc++] Use c++20 instead of c++2a consistently. * The only exception is that the flag -std=c++2a is still used not to break compatibility with older compilers (clang <= 9, gcc <= 9). * Bump _LIBCPP_STD_VER for C++20 to 20 and use 21 for the future standard (C++2b). That's a preparation step to add c++2b support to libc++. Reviewed By: ldionne, #libc Differential Revision: https://reviews.llvm.org/D93383
2021-01-07 12:29:04 +01:00
generic-cxx20)
[libc++] Allow customizing a few paths when running build bots This allows reusing run-buildbot for downstream testing as well.
2020-11-05 19:02:32 -05:00
clean
[libc++] Enable clang-tidy from the buildkite pipeline instead of hard-coding it in run-buildbot Reviewed By: ldionne, #libc, Mordante, emaste Spies: emaste, Mordante, libcxx-commits, arichardson Differential Revision: https://reviews.llvm.org/D141294
2023-01-09 17:45:45 +01:00
generate-cmake -C "${MONOREPO_ROOT}/libcxx/cmake/caches/Generic-cxx20.cmake"
[runtimes][ci] Run the tests for libunwind in the CI We should arguably have always been doing that. The state of libunwind is quite sad, so this commit adds several XFAILs to make the CI pass. We need to investigate why so many tests are not passing in some configurations, but I'll defer that to folks who actually work on libunwind for lack of bandwidth. Differential Revision: https://reviews.llvm.org/D110872
2021-09-30 15:11:48 -04:00
check-runtimes
[libc++] Add basic support for -std=c++2b. * Add feature test macros. * Add buildbot configuration generic-cxx2b that uses clang-tot. Reviewed By: ldionne, #libc Differential Revision: https://reviews.llvm.org/D94227
2021-01-08 18:40:42 +01:00
check-abi-list
;;
[libc++] Updates C++2b to C++23. During the ISO C++ Committee meeting plenary session the C++23 Standard has been voted as technical complete. This updates the reference to c++2b to c++23 and updates the __cplusplus macro. Note since we use clang-tidy 16 a small work-around is needed. Clang knows -std=c++23 but clang-tidy not so for now force the lit compiler flag to use -std=c++2b instead of -std=c++23. Reviewed By: #libc, philnik, jloser, ldionne Differential Revision: https://reviews.llvm.org/D150795
2023-05-17 17:54:53 +02:00
generic-cxx23)
[libc++] Add basic support for -std=c++2b. * Add feature test macros. * Add buildbot configuration generic-cxx2b that uses clang-tot. Reviewed By: ldionne, #libc Differential Revision: https://reviews.llvm.org/D94227
2021-01-08 18:40:42 +01:00
clean
[libc++] Updates C++2b to C++23. During the ISO C++ Committee meeting plenary session the C++23 Standard has been voted as technical complete. This updates the reference to c++2b to c++23 and updates the __cplusplus macro. Note since we use clang-tidy 16 a small work-around is needed. Clang knows -std=c++23 but clang-tidy not so for now force the lit compiler flag to use -std=c++2b instead of -std=c++23. Reviewed By: #libc, philnik, jloser, ldionne Differential Revision: https://reviews.llvm.org/D150795
2023-05-17 17:54:53 +02:00
generate-cmake -C "${MONOREPO_ROOT}/libcxx/cmake/caches/Generic-cxx23.cmake"
[runtimes][ci] Run the tests for libunwind in the CI We should arguably have always been doing that. The state of libunwind is quite sad, so this commit adds several XFAILs to make the CI pass. We need to investigate why so many tests are not passing in some configurations, but I'll defer that to folks who actually work on libunwind for lack of bandwidth. Differential Revision: https://reviews.llvm.org/D110872
2021-09-30 15:11:48 -04:00
check-runtimes
[libc++] Formalize what configurations are covered by the ABI lists By encoding ABI-affecting properties in the name of the ABI list, it makes it clear when an ABI list test should or should not be available, and what results we should expect. Note that we clearly don't encode all ABI-affecting parameters in the name right now -- I just ported over what we supported in the code that was there previously. As we encounter configurations that we wish to support but produce different ABI lists, we can add those to the ABI identifier and start supporting them. This commit also starts checking the ABI list in the CI jobs that run a supported configuration. Eventually, all configurations should have a generated ABI list and the test should even run implicitly as part of the Lit test suite. Differential Revision: https://reviews.llvm.org/D92194
2020-11-26 15:00:42 -05:00
check-abi-list
[libc++] Initial support for pre-commit CI with Buildkite This commit adds basic files and scripts that are used for the Buildkite pre-commit CI setup. This was tested to mostly work on a fork of llvm-project, however some adjustments will have to be made as we complete the real setup.
2020-09-23 09:20:03 -04:00
;;
[libc++] Adds C++26 support. Clang has been updated to support C++26, this adds the same support for libc++. At the moment C++23 and C++26 are identical. During the next plenary in June the first C++26 papers will be voted on. Note like Clang this patch uses C++26 is the internal part and C++2c in the user visible part. Depends on D150795 Reviewed By: ldionne, #libc Differential Revision: https://reviews.llvm.org/D151026
2023-05-20 12:38:57 +02:00
generic-cxx26)
clean
generate-cmake -C "${MONOREPO_ROOT}/libcxx/cmake/caches/Generic-cxx26.cmake"
check-runtimes
check-abi-list
;;
[libc++][NFC] Refactor run-buildbot to make it closer to our buildkite pipeline Differential Revision: https://reviews.llvm.org/D138380
2022-11-18 16:17:10 -05:00
#
# Other compiler support
#
[libc++][ci] Add a job to run the vanilla configuration on Apple Previously, we'd only have jobs testing the Apple cache on Apple platforms, but libc++ should also work out-of-the-box.
2020-10-01 13:55:39 -04:00
generic-gcc)
[libc++] Allow customizing a few paths when running build bots This allows reusing run-buildbot for downstream testing as well.
2020-11-05 19:02:32 -05:00
clean
[libunwind] Tidy-up the testing configuration for libunwind Start testing Apple backdeployment with older libunwinds, and stop explicitly specifying the libunwind testing config, since it is already selected correctly by default. Differential Revision: https://reviews.llvm.org/D126470
2022-05-26 10:19:25 -04:00
generate-cmake -DLIBCXX_ENABLE_WERROR=NO \
[libcxx] [ci] Enable -Werror for libcxxabi and libunwind too Differential Revision: https://reviews.llvm.org/D122800
2022-03-31 11:51:30 +03:00
-DLIBCXXABI_ENABLE_WERROR=NO \
-DLIBUNWIND_ENABLE_WERROR=NO
[runtimes][ci] Run the tests for libunwind in the CI We should arguably have always been doing that. The state of libunwind is quite sad, so this commit adds several XFAILs to make the CI pass. We need to investigate why so many tests are not passing in some configurations, but I'll defer that to folks who actually work on libunwind for lack of bandwidth. Differential Revision: https://reviews.llvm.org/D110872
2021-09-30 15:11:48 -04:00
check-runtimes
[libc++] Initial support for pre-commit CI with Buildkite This commit adds basic files and scripts that are used for the Buildkite pre-commit CI setup. This was tested to mostly work on a fork of llvm-project, however some adjustments will have to be made as we complete the real setup.
2020-09-23 09:20:03 -04:00
;;
[libc++] Add a job running GCC with C++11 This configuration is interesting because GCC has a different level of strictness for some C++ rules. In particular, it implements the older standards more stringently than Clang, which can help find places where we are non-conforming (especially in the test suite). Differential Revision: https://reviews.llvm.org/D105936
2021-07-15 09:46:36 -04:00
generic-gcc-cxx11)
clean
[libc++] Add a from-scratch testing config for GCC Differential Revision: https://reviews.llvm.org/D111329
2021-10-07 14:54:14 -04:00
generate-cmake -C "${MONOREPO_ROOT}/libcxx/cmake/caches/Generic-cxx11.cmake" \
[libcxx] [ci] Enable -Werror for libcxxabi and libunwind too Differential Revision: https://reviews.llvm.org/D122800
2022-03-31 11:51:30 +03:00
-DLIBCXX_ENABLE_WERROR=NO \
-DLIBCXXABI_ENABLE_WERROR=NO \
-DLIBUNWIND_ENABLE_WERROR=NO
[runtimes][ci] Run the tests for libunwind in the CI We should arguably have always been doing that. The state of libunwind is quite sad, so this commit adds several XFAILs to make the CI pass. We need to investigate why so many tests are not passing in some configurations, but I'll defer that to folks who actually work on libunwind for lack of bandwidth. Differential Revision: https://reviews.llvm.org/D110872
2021-09-30 15:11:48 -04:00
check-runtimes
[libc++] Add a job running GCC with C++11 This configuration is interesting because GCC has a different level of strictness for some C++ rules. In particular, it implements the older standards more stringently than Clang, which can help find places where we are non-conforming (especially in the test suite). Differential Revision: https://reviews.llvm.org/D105936
2021-07-15 09:46:36 -04:00
;;
[libc++][NFC] Refactor run-buildbot to make it closer to our buildkite pipeline Differential Revision: https://reviews.llvm.org/D138380
2022-11-18 16:17:10 -05:00
#
# Sanitizers
#
[libc++][ci] Add a job to run the vanilla configuration on Apple Previously, we'd only have jobs testing the Apple cache on Apple platforms, but libc++ should also work out-of-the-box.
2020-10-01 13:55:39 -04:00
generic-asan)
[libc++] Allow customizing a few paths when running build bots This allows reusing run-buildbot for downstream testing as well.
2020-11-05 19:02:32 -05:00
clean
[libunwind] Tidy-up the testing configuration for libunwind Start testing Apple backdeployment with older libunwinds, and stop explicitly specifying the libunwind testing config, since it is already selected correctly by default. Differential Revision: https://reviews.llvm.org/D126470
2022-05-26 10:19:25 -04:00
generate-cmake -C "${MONOREPO_ROOT}/libcxx/cmake/caches/Generic-asan.cmake"
[runtimes][ci] Run the tests for libunwind in the CI We should arguably have always been doing that. The state of libunwind is quite sad, so this commit adds several XFAILs to make the CI pass. We need to investigate why so many tests are not passing in some configurations, but I'll defer that to folks who actually work on libunwind for lack of bandwidth. Differential Revision: https://reviews.llvm.org/D110872
2021-09-30 15:11:48 -04:00
check-runtimes
[libc++] Initial support for pre-commit CI with Buildkite This commit adds basic files and scripts that are used for the Buildkite pre-commit CI setup. This was tested to mostly work on a fork of llvm-project, however some adjustments will have to be made as we complete the real setup.
2020-09-23 09:20:03 -04:00
;;
[libc++][ci] Add a job to run the vanilla configuration on Apple Previously, we'd only have jobs testing the Apple cache on Apple platforms, but libc++ should also work out-of-the-box.
2020-10-01 13:55:39 -04:00
generic-msan)
[libc++] Allow customizing a few paths when running build bots This allows reusing run-buildbot for downstream testing as well.
2020-11-05 19:02:32 -05:00
clean
[libunwind] Tidy-up the testing configuration for libunwind Start testing Apple backdeployment with older libunwinds, and stop explicitly specifying the libunwind testing config, since it is already selected correctly by default. Differential Revision: https://reviews.llvm.org/D126470
2022-05-26 10:19:25 -04:00
generate-cmake -C "${MONOREPO_ROOT}/libcxx/cmake/caches/Generic-msan.cmake"
[runtimes][ci] Run the tests for libunwind in the CI We should arguably have always been doing that. The state of libunwind is quite sad, so this commit adds several XFAILs to make the CI pass. We need to investigate why so many tests are not passing in some configurations, but I'll defer that to folks who actually work on libunwind for lack of bandwidth. Differential Revision: https://reviews.llvm.org/D110872
2021-09-30 15:11:48 -04:00
check-runtimes
[libc++] Initial support for pre-commit CI with Buildkite This commit adds basic files and scripts that are used for the Buildkite pre-commit CI setup. This was tested to mostly work on a fork of llvm-project, however some adjustments will have to be made as we complete the real setup.
2020-09-23 09:20:03 -04:00
;;
[libc++][ci] Add a job to run the vanilla configuration on Apple Previously, we'd only have jobs testing the Apple cache on Apple platforms, but libc++ should also work out-of-the-box.
2020-10-01 13:55:39 -04:00
generic-tsan)
[libc++] Allow customizing a few paths when running build bots This allows reusing run-buildbot for downstream testing as well.
2020-11-05 19:02:32 -05:00
clean
[libunwind] Tidy-up the testing configuration for libunwind Start testing Apple backdeployment with older libunwinds, and stop explicitly specifying the libunwind testing config, since it is already selected correctly by default. Differential Revision: https://reviews.llvm.org/D126470
2022-05-26 10:19:25 -04:00
generate-cmake -C "${MONOREPO_ROOT}/libcxx/cmake/caches/Generic-tsan.cmake"
[runtimes][ci] Run the tests for libunwind in the CI We should arguably have always been doing that. The state of libunwind is quite sad, so this commit adds several XFAILs to make the CI pass. We need to investigate why so many tests are not passing in some configurations, but I'll defer that to folks who actually work on libunwind for lack of bandwidth. Differential Revision: https://reviews.llvm.org/D110872
2021-09-30 15:11:48 -04:00
check-runtimes
[libc++] Initial support for pre-commit CI with Buildkite This commit adds basic files and scripts that are used for the Buildkite pre-commit CI setup. This was tested to mostly work on a fork of llvm-project, however some adjustments will have to be made as we complete the real setup.
2020-09-23 09:20:03 -04:00
;;
[libc++][ci] Add a job to run the vanilla configuration on Apple Previously, we'd only have jobs testing the Apple cache on Apple platforms, but libc++ should also work out-of-the-box.
2020-10-01 13:55:39 -04:00
generic-ubsan)
[libc++] Allow customizing a few paths when running build bots This allows reusing run-buildbot for downstream testing as well.
2020-11-05 19:02:32 -05:00
clean
[libunwind] Tidy-up the testing configuration for libunwind Start testing Apple backdeployment with older libunwinds, and stop explicitly specifying the libunwind testing config, since it is already selected correctly by default. Differential Revision: https://reviews.llvm.org/D126470
2022-05-26 10:19:25 -04:00
generate-cmake -C "${MONOREPO_ROOT}/libcxx/cmake/caches/Generic-ubsan.cmake"
[runtimes][ci] Run the tests for libunwind in the CI We should arguably have always been doing that. The state of libunwind is quite sad, so this commit adds several XFAILs to make the CI pass. We need to investigate why so many tests are not passing in some configurations, but I'll defer that to folks who actually work on libunwind for lack of bandwidth. Differential Revision: https://reviews.llvm.org/D110872
2021-09-30 15:11:48 -04:00
check-runtimes
[libc++] Initial support for pre-commit CI with Buildkite This commit adds basic files and scripts that are used for the Buildkite pre-commit CI setup. This was tested to mostly work on a fork of llvm-project, however some adjustments will have to be made as we complete the real setup.
2020-09-23 09:20:03 -04:00
;;
[libc++][NFC] Refactor run-buildbot to make it closer to our buildkite pipeline Differential Revision: https://reviews.llvm.org/D138380
2022-11-18 16:17:10 -05:00
#
# Various build configurations
#
bootstrapping-build)
[libc++] Allow customizing a few paths when running build bots This allows reusing run-buildbot for downstream testing as well.
2020-11-05 19:02:32 -05:00
clean
[libc++][NFC] Refactor run-buildbot to make it closer to our buildkite pipeline Differential Revision: https://reviews.llvm.org/D138380
2022-11-18 16:17:10 -05:00
[libc++] Add output groups to run-buildbot (#111739) This improves the CI output by providing collapsable sections for sub-parts of our build. This was originally opened as #75233. Co-authored-by: eric <eric@efcs.ca>
2024-10-11 09:29:47 -04:00
step "Generating CMake"
[libc++][NFC] Refactor run-buildbot to make it closer to our buildkite pipeline Differential Revision: https://reviews.llvm.org/D138380
2022-11-18 16:17:10 -05:00
${CMAKE} \
-S "${MONOREPO_ROOT}/llvm" \
-B "${BUILD_DIR}" \
-GNinja -DCMAKE_MAKE_PROGRAM="${NINJA}" \
[libc++][ci] Use ccache in the jobs that build Clang This is an attempt to reduce the time taken by the Bootstrapping build job and the Clang CI job that builds the compiler from scratch. Differential Revision: https://reviews.llvm.org/D150908
2023-05-18 14:16:24 -07:00
-DCMAKE_CXX_COMPILER_LAUNCHER="ccache" \
[lib++][CI] Changes bootstrap build type. (#88175) The RelWithDebInfo generates a few GB of debug info that is not used. Instead use the normal Release build for testing.
2024-04-10 08:02:13 +02:00
-DCMAKE_BUILD_TYPE=Release \
[libc++][NFC] Refactor run-buildbot to make it closer to our buildkite pipeline Differential Revision: https://reviews.llvm.org/D138380
2022-11-18 16:17:10 -05:00
-DCMAKE_INSTALL_PREFIX="${INSTALL_DIR}" \
[libc++][CI] Tests LLDB libc++ data formatters. (#88312) This enables testing of the LLDB libc++ specific data formatters. This is enabled in the bootstrap build since building LLDB requires Clang and this is quite expensive. Adding this test changes the build time from 31 to 34 minutes.
2024-04-15 17:58:37 +02:00
-DLLVM_ENABLE_PROJECTS="clang;lldb" \
[libc++][NFC] Refactor run-buildbot to make it closer to our buildkite pipeline Differential Revision: https://reviews.llvm.org/D138380
2022-11-18 16:17:10 -05:00
-DLLVM_ENABLE_RUNTIMES="libcxx;libcxxabi;libunwind" \
[libc++] Use $CXX instead of 'c++' in run-buildbot We don't have `c++` anymore in the Docker image, but the script does require $CXX to be in the environment so that should always work. Differential Revision: https://reviews.llvm.org/D148830
2023-04-20 15:06:41 -04:00
-DLLVM_RUNTIME_TARGETS="$(${CXX} --print-target-triple)" \
[libc++][CI] Tests LLDB libc++ data formatters. (#88312) This enables testing of the LLDB libc++ specific data formatters. This is enabled in the bootstrap build since building LLDB requires Clang and this is quite expensive. Adding this test changes the build time from 31 to 34 minutes.
2024-04-15 17:58:37 +02:00
-DLLVM_HOST_TRIPLE="$(${CXX} --print-target-triple)" \
[libc++][NFC] Refactor run-buildbot to make it closer to our buildkite pipeline Differential Revision: https://reviews.llvm.org/D138380
2022-11-18 16:17:10 -05:00
-DLLVM_TARGETS_TO_BUILD="host" \
-DRUNTIMES_BUILD_ALLOW_DARWIN=ON \
[libc++][CI] Improves bootstrap build output. Use the same arguments as other builds. This gives better output to validate what the CI did. Reviewed By: #libc, ldionne Differential Revision: https://reviews.llvm.org/D158860
2023-08-25 18:40:48 +02:00
-DLLVM_ENABLE_ASSERTIONS=ON \
Improve CI output. (#70236) There is currently a major problem with the CI output: The information you need to see never appears in the visible log. This is because our logs are very verbose, and list (A) every test as they run it, and (B) every unsupported tests. This can be thousands of lines. (A) was introduced by me when I disabled the PTY progress bar, which doesn't play nice with log files. That change was an improvement, but I have now disabled the PTY on the builders, so we can go back to passing `-s`. When `-s` is passed but no PTY is available, it prints a long friendly progress indicator. (B) is solved here by disabling the printing of unsupported tests at the end of the test suite. While it can be useful on occasion to audit the list of unsupported tests, it's far from a common operation. Instead people want to see the log of their failure. We should upload the xml results, so if auditing is needed, it can be done using that. Hopefully this change will make it so that the test failures appear in the actual log output
2023-10-25 18:10:29 -04:00
-DLLVM_LIT_ARGS="-sv --xunit-xml-output test-results.xml --timeout=1500 --time-tests"
[libc++][NFC] Refactor run-buildbot to make it closer to our buildkite pipeline Differential Revision: https://reviews.llvm.org/D138380
2022-11-18 16:17:10 -05:00
[libc++] Add output groups to run-buildbot (#111739) This improves the CI output by providing collapsable sections for sub-parts of our build. This was originally opened as #75233. Co-authored-by: eric <eric@efcs.ca>
2024-10-11 09:29:47 -04:00
step "Running the LLDB libc++ data formatter tests"
[libc++][CI] Replace LLDB test targets with libc++ test category (#110856) We've been increasing the coverage of libc++ LLDB tests in the pre-merge CI (see https://github.com/llvm/llvm-project/pull/110570). Unfortunately the tests are spread across different targets. It would be great if we had a single target that libc++ maintainers could run. We do this by passing the `libc++` test-category as a parameter to LLDB's [`dotest` testing framework](https://lldb.llvm.org/resources/test.html). This will only run LLDB tests that have been marked as belonging to the `libc++` category.
2024-10-08 10:21:51 +02:00
${NINJA} -vC "${BUILD_DIR}" lldb-api-test-deps
${BUILD_DIR}/bin/llvm-lit -sv --param dotest-args='--category libc++' "${MONOREPO_ROOT}/lldb/test/API"
[libc++][CI] Tests LLDB libc++ data formatters. (#88312) This enables testing of the LLDB libc++ specific data formatters. This is enabled in the bootstrap build since building LLDB requires Clang and this is quite expensive. Adding this test changes the build time from 31 to 34 minutes.
2024-04-15 17:58:37 +02:00
[libc++] Add output groups to run-buildbot (#111739) This improves the CI output by providing collapsable sections for sub-parts of our build. This was originally opened as #75233. Co-authored-by: eric <eric@efcs.ca>
2024-10-11 09:29:47 -04:00
step "Running the libc++ and libc++abi tests"
[libc++][CI] Improves bootstrap build output. Use the same arguments as other builds. This gives better output to validate what the CI did. Reviewed By: #libc, ldionne Differential Revision: https://reviews.llvm.org/D158860
2023-08-25 18:40:48 +02:00
${NINJA} -vC "${BUILD_DIR}" check-runtimes
[libc++][NFC] Refactor run-buildbot to make it closer to our buildkite pipeline Differential Revision: https://reviews.llvm.org/D138380
2022-11-18 16:17:10 -05:00
[libc++] Add output groups to run-buildbot (#111739) This improves the CI output by providing collapsable sections for sub-parts of our build. This was originally opened as #75233. Co-authored-by: eric <eric@efcs.ca>
2024-10-11 09:29:47 -04:00
step "Installing libc++ and libc++abi to a fake location"
[libc++][CI] Improves bootstrap build output. Use the same arguments as other builds. This gives better output to validate what the CI did. Reviewed By: #libc, ldionne Differential Revision: https://reviews.llvm.org/D158860
2023-08-25 18:40:48 +02:00
${NINJA} -vC "${BUILD_DIR}" install-runtimes
[libc++] Extract ccache stats after the bootstrapping build
2023-06-01 13:16:19 -07:00
ccache -s
[libc++][NFC] Refactor run-buildbot to make it closer to our buildkite pipeline Differential Revision: https://reviews.llvm.org/D138380
2022-11-18 16:17:10 -05:00
;;
generic-static)
clean
generate-cmake -C "${MONOREPO_ROOT}/libcxx/cmake/caches/Generic-static.cmake"
check-runtimes
;;
generic-merged)
clean
generate-cmake -C "${MONOREPO_ROOT}/libcxx/cmake/caches/Generic-merged.cmake" \
-DLIBCXX_TEST_CONFIG="llvm-libc++-shared.cfg.in" \
-DLIBCXXABI_TEST_CONFIG="llvm-libc++abi-merged.cfg.in" \
-DLIBUNWIND_TEST_CONFIG="llvm-libunwind-merged.cfg.in"
check-runtimes
;;
[libc++][hardening] Rework macros for enabling the hardening mode. (#70575) 1. Instead of using individual "boolean" macros, have an "enum" macro `_LIBCPP_HARDENING_MODE`. This avoids issues with macros being mutually exclusive and makes overriding the hardening mode within a TU more straightforward. 2. Rename the safe mode to debug-lite. This brings the code in line with the RFC: https://discourse.llvm.org/t/rfc-hardening-in-libc/73925 Fixes #65101
2023-11-08 09:10:00 -10:00
generic-hardening-mode-fast)
[libc++][hardening][NFC] Add macros to enable hardened mode. This patch only adds new configuration knobs -- the actual assertions will be added in follow-up patches. Differential Revision: https://reviews.llvm.org/D153902
2023-07-12 10:12:51 -07:00
clean
[libc++][hardening] Rework macros for enabling the hardening mode. (#70575) 1. Instead of using individual "boolean" macros, have an "enum" macro `_LIBCPP_HARDENING_MODE`. This avoids issues with macros being mutually exclusive and makes overriding the hardening mode within a TU more straightforward. 2. Rename the safe mode to debug-lite. This brings the code in line with the RFC: https://discourse.llvm.org/t/rfc-hardening-in-libc/73925 Fixes #65101
2023-11-08 09:10:00 -10:00
generate-cmake -C "${MONOREPO_ROOT}/libcxx/cmake/caches/Generic-hardening-mode-fast.cmake"
[libc++][hardening][NFC] Add macros to enable hardened mode. This patch only adds new configuration knobs -- the actual assertions will be added in follow-up patches. Differential Revision: https://reviews.llvm.org/D153902
2023-07-12 10:12:51 -07:00
check-runtimes
check-abi-list
;;
[libc++][hardening] Rework macros for enabling the hardening mode. (#70575) 1. Instead of using individual "boolean" macros, have an "enum" macro `_LIBCPP_HARDENING_MODE`. This avoids issues with macros being mutually exclusive and makes overriding the hardening mode within a TU more straightforward. 2. Rename the safe mode to debug-lite. This brings the code in line with the RFC: https://discourse.llvm.org/t/rfc-hardening-in-libc/73925 Fixes #65101
2023-11-08 09:10:00 -10:00
generic-hardening-mode-fast-with-abi-breaks)
[libc++][hardening] Add tests for the hardened mode with ABI breaks. (#71020) Add a new test mode that enables the hardened mode in combination with ABI-breaking changes (only bounded iterators currently) and reenable the bounded iterator tests for `span` and `string_view`.
2023-11-03 06:46:19 -07:00
clean
[libc++][hardening] Rework macros for enabling the hardening mode. (#70575) 1. Instead of using individual "boolean" macros, have an "enum" macro `_LIBCPP_HARDENING_MODE`. This avoids issues with macros being mutually exclusive and makes overriding the hardening mode within a TU more straightforward. 2. Rename the safe mode to debug-lite. This brings the code in line with the RFC: https://discourse.llvm.org/t/rfc-hardening-in-libc/73925 Fixes #65101
2023-11-08 09:10:00 -10:00
generate-cmake -C "${MONOREPO_ROOT}/libcxx/cmake/caches/Generic-hardening-mode-fast-with-abi-breaks.cmake"
[libc++][hardening] Add tests for the hardened mode with ABI breaks. (#71020) Add a new test mode that enables the hardened mode in combination with ABI-breaking changes (only bounded iterators currently) and reenable the bounded iterator tests for `span` and `string_view`.
2023-11-03 06:46:19 -07:00
check-runtimes
[libc++] Fix CMake cache for the hardening with ABI breaks CI (#105864) We were incorrectly only enabling _LIBCPP_ABI_BOUNDED_ITERATORS, without enabling bounded iterators in string and vector.
2024-08-26 17:16:37 -04:00
# Not checking ABI list since we purposefully enable ABI breaking changes
[libc++][hardening] Add tests for the hardened mode with ABI breaks. (#71020) Add a new test mode that enables the hardened mode in combination with ABI-breaking changes (only bounded iterators currently) and reenable the bounded iterator tests for `span` and `string_view`.
2023-11-03 06:46:19 -07:00
;;
[libc++][hardening] Rework macros for enabling the hardening mode. (#70575) 1. Instead of using individual "boolean" macros, have an "enum" macro `_LIBCPP_HARDENING_MODE`. This avoids issues with macros being mutually exclusive and makes overriding the hardening mode within a TU more straightforward. 2. Rename the safe mode to debug-lite. This brings the code in line with the RFC: https://discourse.llvm.org/t/rfc-hardening-in-libc/73925 Fixes #65101
2023-11-08 09:10:00 -10:00
generic-hardening-mode-extensive)
[libc++][hardening] Add back the safe mode. The safe mode is in-between the hardened and the debug modes, extending the checks contained in the hardened mode with certain checks that are relatively cheap and prevent common sources of errors but aren't security-critical. Thus, the safe mode trades off some performance for a wider set of checks, but unlike the debug mode, it can still be used in production. Differential Revision: https://reviews.llvm.org/D158823
2023-09-12 12:01:36 -07:00
clean
[libc++][hardening] Rework macros for enabling the hardening mode. (#70575) 1. Instead of using individual "boolean" macros, have an "enum" macro `_LIBCPP_HARDENING_MODE`. This avoids issues with macros being mutually exclusive and makes overriding the hardening mode within a TU more straightforward. 2. Rename the safe mode to debug-lite. This brings the code in line with the RFC: https://discourse.llvm.org/t/rfc-hardening-in-libc/73925 Fixes #65101
2023-11-08 09:10:00 -10:00
generate-cmake -C "${MONOREPO_ROOT}/libcxx/cmake/caches/Generic-hardening-mode-extensive.cmake"
[libc++][hardening] Add back the safe mode. The safe mode is in-between the hardened and the debug modes, extending the checks contained in the hardened mode with certain checks that are relatively cheap and prevent common sources of errors but aren't security-critical. Thus, the safe mode trades off some performance for a wider set of checks, but unlike the debug mode, it can still be used in production. Differential Revision: https://reviews.llvm.org/D158823
2023-09-12 12:01:36 -07:00
check-runtimes
check-abi-list
;;
[libc++][hardening] Rework macros for enabling the hardening mode. (#70575) 1. Instead of using individual "boolean" macros, have an "enum" macro `_LIBCPP_HARDENING_MODE`. This avoids issues with macros being mutually exclusive and makes overriding the hardening mode within a TU more straightforward. 2. Rename the safe mode to debug-lite. This brings the code in line with the RFC: https://discourse.llvm.org/t/rfc-hardening-in-libc/73925 Fixes #65101
2023-11-08 09:10:00 -10:00
generic-hardening-mode-debug)
[libc++][hardening][NFC] Add macros to enable hardened mode. This patch only adds new configuration knobs -- the actual assertions will be added in follow-up patches. Differential Revision: https://reviews.llvm.org/D153902
2023-07-12 10:12:51 -07:00
clean
[libc++][hardening] Rework macros for enabling the hardening mode. (#70575) 1. Instead of using individual "boolean" macros, have an "enum" macro `_LIBCPP_HARDENING_MODE`. This avoids issues with macros being mutually exclusive and makes overriding the hardening mode within a TU more straightforward. 2. Rename the safe mode to debug-lite. This brings the code in line with the RFC: https://discourse.llvm.org/t/rfc-hardening-in-libc/73925 Fixes #65101
2023-11-08 09:10:00 -10:00
generate-cmake -C "${MONOREPO_ROOT}/libcxx/cmake/caches/Generic-hardening-mode-debug.cmake"
[libc++][hardening][NFC] Add macros to enable hardened mode. This patch only adds new configuration knobs -- the actual assertions will be added in follow-up patches. Differential Revision: https://reviews.llvm.org/D153902
2023-07-12 10:12:51 -07:00
check-runtimes
check-abi-list
;;
[libc++][modules] Adds the C++23 std module. The patch is based on D144994. D151030 added the module definitions for the module std. This patch wires in the module and enables the basic testing. Some notable features are missing: - There is no test that libc++ can be fully imported as a module. - This lacks the parts for the std.compat module. - The module is not shipped with libc++. Implements parts of - P2465R3 Standard Library Modules std and std.compat Reviewed By: ldionne, aaronmondal, #libc Differential Revision: https://reviews.llvm.org/D151814
2023-02-28 20:29:26 +01:00
#
# Module builds
#
[libc++][NFC] Refactor run-buildbot to make it closer to our buildkite pipeline Differential Revision: https://reviews.llvm.org/D138380
2022-11-18 16:17:10 -05:00
generic-modules)
clean
generate-cmake -C "${MONOREPO_ROOT}/libcxx/cmake/caches/Generic-modules.cmake"
check-runtimes
check-abi-list
;;
[libc++] Add a CI configuration to test Modules with LSV enabled Some clients use libc++ with modules and LSV (Local Submodule Visibility) enabled, and we see frequent downstream breakage caused by that. Until modules use LSV by default (which is apparently a desire), add a CI job that tests this sub-configuration to avoid high cost downstream breakage. For more information about LSV, see https://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20150504/128395.html. Differential Revision: https://reviews.llvm.org/D143273
2023-02-02 18:50:10 -05:00
generic-modules-lsv)
clean
generate-cmake -C "${MONOREPO_ROOT}/libcxx/cmake/caches/Generic-modules-lsv.cmake"
check-runtimes
check-abi-list
;;
[libc++][NFC] Refactor run-buildbot to make it closer to our buildkite pipeline Differential Revision: https://reviews.llvm.org/D138380
2022-11-18 16:17:10 -05:00
#
# Parts removed
#
[libc++] Rename the generic-singlethreaded CI job to generic-no-threads for consistency
2022-05-24 09:58:04 -04:00
generic-no-threads)
[libc++] Allow customizing a few paths when running build bots This allows reusing run-buildbot for downstream testing as well.
2020-11-05 19:02:32 -05:00
clean
[libunwind] Tidy-up the testing configuration for libunwind Start testing Apple backdeployment with older libunwinds, and stop explicitly specifying the libunwind testing config, since it is already selected correctly by default. Differential Revision: https://reviews.llvm.org/D126470
2022-05-26 10:19:25 -04:00
generate-cmake -C "${MONOREPO_ROOT}/libcxx/cmake/caches/Generic-no-threads.cmake"
[runtimes][ci] Run the tests for libunwind in the CI We should arguably have always been doing that. The state of libunwind is quite sad, so this commit adds several XFAILs to make the CI pass. We need to investigate why so many tests are not passing in some configurations, but I'll defer that to folks who actually work on libunwind for lack of bandwidth. Differential Revision: https://reviews.llvm.org/D110872
2021-09-30 15:11:48 -04:00
check-runtimes
[libc++] Initial support for pre-commit CI with Buildkite This commit adds basic files and scripts that are used for the Buildkite pre-commit CI setup. This was tested to mostly work on a fork of llvm-project, however some adjustments will have to be made as we complete the real setup.
2020-09-23 09:20:03 -04:00
;;
[libc++] Make LIBCXX_ENABLE_FILESYSTEM fully consistent Previously, LIBCXX_ENABLE_FILESYSTEM controlled only whether the filesystem support was compiled into libc++'s library. This commit promotes the setting to a first-class option like LIBCXX_ENABLE_LOCALIZATION, where the whole library is aware of the setting and features that depend on <filesystem> won't be provided at all. The test suite is also properly annotated such that tests that depend on <filesystem> are disabled when the library doesn't support it. This is an alternative to https://llvm.org/D94824, but also an improvement along the lines of LIBCXX_ENABLE_LOCALIZATION that I had been wanting to make for a while. Differential Revision: https://reviews.llvm.org/D94921
2021-01-18 12:18:18 -05:00
generic-no-filesystem)
clean
[libunwind] Tidy-up the testing configuration for libunwind Start testing Apple backdeployment with older libunwinds, and stop explicitly specifying the libunwind testing config, since it is already selected correctly by default. Differential Revision: https://reviews.llvm.org/D126470
2022-05-26 10:19:25 -04:00
generate-cmake -C "${MONOREPO_ROOT}/libcxx/cmake/caches/Generic-no-filesystem.cmake"
[runtimes][ci] Run the tests for libunwind in the CI We should arguably have always been doing that. The state of libunwind is quite sad, so this commit adds several XFAILs to make the CI pass. We need to investigate why so many tests are not passing in some configurations, but I'll defer that to folks who actually work on libunwind for lack of bandwidth. Differential Revision: https://reviews.llvm.org/D110872
2021-09-30 15:11:48 -04:00
check-runtimes
[libc++] Make LIBCXX_ENABLE_FILESYSTEM fully consistent Previously, LIBCXX_ENABLE_FILESYSTEM controlled only whether the filesystem support was compiled into libc++'s library. This commit promotes the setting to a first-class option like LIBCXX_ENABLE_LOCALIZATION, where the whole library is aware of the setting and features that depend on <filesystem> won't be provided at all. The test suite is also properly annotated such that tests that depend on <filesystem> are disabled when the library doesn't support it. This is an alternative to https://llvm.org/D94824, but also an improvement along the lines of LIBCXX_ENABLE_LOCALIZATION that I had been wanting to make for a while. Differential Revision: https://reviews.llvm.org/D94921
2021-01-18 12:18:18 -05:00
;;
[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 10:32:09 -04:00
generic-no-random_device)
[libc++] Allow customizing a few paths when running build bots This allows reusing run-buildbot for downstream testing as well.
2020-11-05 19:02:32 -05:00
clean
[libunwind] Tidy-up the testing configuration for libunwind Start testing Apple backdeployment with older libunwinds, and stop explicitly specifying the libunwind testing config, since it is already selected correctly by default. Differential Revision: https://reviews.llvm.org/D126470
2022-05-26 10:19:25 -04:00
generate-cmake -C "${MONOREPO_ROOT}/libcxx/cmake/caches/Generic-no-random_device.cmake"
[runtimes][ci] Run the tests for libunwind in the CI We should arguably have always been doing that. The state of libunwind is quite sad, so this commit adds several XFAILs to make the CI pass. We need to investigate why so many tests are not passing in some configurations, but I'll defer that to folks who actually work on libunwind for lack of bandwidth. Differential Revision: https://reviews.llvm.org/D110872
2021-09-30 15:11:48 -04:00
check-runtimes
[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 10:32:09 -04:00
;;
[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-09 15:31:05 -04:00
generic-no-localization)
[libc++] Allow customizing a few paths when running build bots This allows reusing run-buildbot for downstream testing as well.
2020-11-05 19:02:32 -05:00
clean
[libunwind] Tidy-up the testing configuration for libunwind Start testing Apple backdeployment with older libunwinds, and stop explicitly specifying the libunwind testing config, since it is already selected correctly by default. Differential Revision: https://reviews.llvm.org/D126470
2022-05-26 10:19:25 -04:00
generate-cmake -C "${MONOREPO_ROOT}/libcxx/cmake/caches/Generic-no-localization.cmake"
[runtimes][ci] Run the tests for libunwind in the CI We should arguably have always been doing that. The state of libunwind is quite sad, so this commit adds several XFAILs to make the CI pass. We need to investigate why so many tests are not passing in some configurations, but I'll defer that to folks who actually work on libunwind for lack of bandwidth. Differential Revision: https://reviews.llvm.org/D110872
2021-09-30 15:11:48 -04:00
check-runtimes
[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-09 15:31:05 -04:00
;;
[libcxx] Add `LIBCXX_HAS_TERMINAL_AVAILABLE` CMake option to disable `print` terminal checks (#99259) Adds a new CMake option called `LIBCXX_HAS_TERMINAL_AVAILABLE` that prevents us from checking for `isatty`.
2024-08-21 08:48:53 -05:00
generic-no-terminal)
clean
generate-cmake -C "${MONOREPO_ROOT}/libcxx/cmake/caches/Generic-no-terminal.cmake"
check-runtimes
;;
[libc++][format] Add a CMake Unicode option. This option is used to select between the format headers output column width option. This option should be independent of the locale setting. It's encouraged to default to Unicode unless the platform doesn't offer that option. [format.string.std]/10 ``` For the purposes of width computation, a string is assumed to be in a locale-independent, implementation-defined encoding. Implementations should use a Unicode encoding on platforms capable of displaying Unicode ``` Reviewed By: #libc, ldionne, vitaut Differential Revision: https://reviews.llvm.org/D103379
2021-05-25 20:11:08 +02:00
generic-no-unicode)
clean
[libunwind] Tidy-up the testing configuration for libunwind Start testing Apple backdeployment with older libunwinds, and stop explicitly specifying the libunwind testing config, since it is already selected correctly by default. Differential Revision: https://reviews.llvm.org/D126470
2022-05-26 10:19:25 -04:00
generate-cmake -C "${MONOREPO_ROOT}/libcxx/cmake/caches/Generic-no-unicode.cmake"
[runtimes][ci] Run the tests for libunwind in the CI We should arguably have always been doing that. The state of libunwind is quite sad, so this commit adds several XFAILs to make the CI pass. We need to investigate why so many tests are not passing in some configurations, but I'll defer that to folks who actually work on libunwind for lack of bandwidth. Differential Revision: https://reviews.llvm.org/D110872
2021-09-30 15:11:48 -04:00
check-runtimes
[libc++][format] Add a CMake Unicode option. This option is used to select between the format headers output column width option. This option should be independent of the locale setting. It's encouraged to default to Unicode unless the platform doesn't offer that option. [format.string.std]/10 ``` For the purposes of width computation, a string is assumed to be in a locale-independent, implementation-defined encoding. Implementations should use a Unicode encoding on platforms capable of displaying Unicode ``` Reviewed By: #libc, ldionne, vitaut Differential Revision: https://reviews.llvm.org/D103379
2021-05-25 20:11:08 +02:00
;;
[libc++] Add an option to disable wide character support in libc++ Some embedded platforms do not wish to support the C library functionality for handling wchar_t because they have no use for it. It makes sense for libc++ to work properly on those platforms, so this commit adds a carve-out of functionality for wchar_t. Unfortunately, unlike some other carve-outs (e.g. random device), this patch touches several parts of the library. However, despite the wide impact of this patch, I still think it is important to support this configuration since it makes it much simpler to port libc++ to some embedded platforms. Differential Revision: https://reviews.llvm.org/D111265
2021-08-23 15:32:36 -04:00
generic-no-wide-characters)
clean
[libunwind] Tidy-up the testing configuration for libunwind Start testing Apple backdeployment with older libunwinds, and stop explicitly specifying the libunwind testing config, since it is already selected correctly by default. Differential Revision: https://reviews.llvm.org/D126470
2022-05-26 10:19:25 -04:00
generate-cmake -C "${MONOREPO_ROOT}/libcxx/cmake/caches/Generic-no-wide-characters.cmake"
[libc++] Add an option to disable wide character support in libc++ Some embedded platforms do not wish to support the C library functionality for handling wchar_t because they have no use for it. It makes sense for libc++ to work properly on those platforms, so this commit adds a carve-out of functionality for wchar_t. Unfortunately, unlike some other carve-outs (e.g. random device), this patch touches several parts of the library. However, despite the wide impact of this patch, I still think it is important to support this configuration since it makes it much simpler to port libc++ to some embedded platforms. Differential Revision: https://reviews.llvm.org/D111265
2021-08-23 15:32:36 -04:00
check-runtimes
;;
[libc++][chrono] Adds tzdb_list implementation. This is the first step to implement time zone support in libc++. This adds the complete tzdb_list class and a minimal tzdb class. The tzdb class only contains the version, which is used by reload_tzdb. Next to these classes it contains documentation and build system support needed for time zone support. The code depends on the IANA Time Zone Database, which should be available on the platform used or provided by the libc++ vendors. The code is labeled as experimental since there will be ABI breaks during development; the tzdb class needs to have the standard headers. Implements parts of: - P0355 Extending <chrono> to Calendars and Time Zones Addresses: - LWG3319 Properly reference specification of IANA time zone database Reviewed By: #libc, ldionne Differential Revision: https://reviews.llvm.org/D154282
2022-09-23 18:33:20 +02:00
generic-no-tzdb)
clean
generate-cmake -C "${MONOREPO_ROOT}/libcxx/cmake/caches/Generic-no-tzdb.cmake"
check-runtimes
;;
[libc++] Add CI without experimental features and don't exclude span from the tests There is no reason for the parts of std::span that don't depend on ranges to be disabled when ranges aren't provided. Also, to make sure the "no-experimental-stuff" configuration is tested, add a CI job for it. Differential Revision: https://reviews.llvm.org/D118740
2022-02-01 16:32:39 -05:00
generic-no-experimental)
clean
[libunwind] Tidy-up the testing configuration for libunwind Start testing Apple backdeployment with older libunwinds, and stop explicitly specifying the libunwind testing config, since it is already selected correctly by default. Differential Revision: https://reviews.llvm.org/D126470
2022-05-26 10:19:25 -04:00
generate-cmake -C "${MONOREPO_ROOT}/libcxx/cmake/caches/Generic-no-experimental.cmake"
[libc++] Add CI without experimental features and don't exclude span from the tests There is no reason for the parts of std::span that don't depend on ranges to be disabled when ranges aren't provided. Also, to make sure the "no-experimental-stuff" configuration is tested, add a CI job for it. Differential Revision: https://reviews.llvm.org/D118740
2022-02-01 16:32:39 -05:00
check-runtimes
[libc++] Take more knobs into account when generating ABI lists This change will make it possible to track exported symbols in more configurations, notably the Apple system one, where we disable incomplete features and the debug mode. Also, as a fly-by fix, shorten the name for whether new is in libc++ or not. Differential Revision: https://reviews.llvm.org/D119764
2022-02-14 14:39:17 -05:00
check-abi-list
[libc++] Add CI without experimental features and don't exclude span from the tests There is no reason for the parts of std::span that don't depend on ranges to be disabled when ranges aren't provided. Also, to make sure the "no-experimental-stuff" configuration is tested, add a CI job for it. Differential Revision: https://reviews.llvm.org/D118740
2022-02-01 16:32:39 -05:00
;;
[libc++][NFC] Rename the 'noexceptions' CI config to 'no-exceptions' for consistency Differential Revision: https://reviews.llvm.org/D150672
2023-05-16 07:48:13 -07:00
generic-no-exceptions)
[libc++][NFC] Refactor run-buildbot to make it closer to our buildkite pipeline Differential Revision: https://reviews.llvm.org/D138380
2022-11-18 16:17:10 -05:00
clean
[libc++][NFC] Rename the 'noexceptions' CI config to 'no-exceptions' for consistency Differential Revision: https://reviews.llvm.org/D150672
2023-05-16 07:48:13 -07:00
generate-cmake -C "${MONOREPO_ROOT}/libcxx/cmake/caches/Generic-no-exceptions.cmake"
[libc++][NFC] Refactor run-buildbot to make it closer to our buildkite pipeline Differential Revision: https://reviews.llvm.org/D138380
2022-11-18 16:17:10 -05:00
check-runtimes
check-abi-list
;;
[libc++][CI] Tests the no RTTI configuration. (#65518) There are a few drive-by fixes: - Since the combination RTTI disabled and exceptions enabled do not work, this combination is prohibited. - A small NFC in any fixing clang-tidy. The code in the Buildkite configuration is prepared for using the std module. There are more fixes needed for that configuration which will be done in a separate commit.
2023-12-12 17:11:53 +01:00
generic-no-rtti)
clean
generate-cmake -C "${MONOREPO_ROOT}/libcxx/cmake/caches/Generic-no-rtti.cmake"
check-runtimes
;;
[libc++][NFC] Refactor run-buildbot to make it closer to our buildkite pipeline Differential Revision: https://reviews.llvm.org/D138380
2022-11-18 16:17:10 -05:00
#
# Other miscellaneous jobs
#
[libc++] Add Unstable ABI CI run Reviewed By: ldionne, #libc, Mordante Spies: mgorny, Mordante, libcxx-commits, arichardson Differential Revision: https://reviews.llvm.org/D118725
2022-02-05 14:09:45 +01:00
generic-abi-unstable)
clean
[libunwind] Tidy-up the testing configuration for libunwind Start testing Apple backdeployment with older libunwinds, and stop explicitly specifying the libunwind testing config, since it is already selected correctly by default. Differential Revision: https://reviews.llvm.org/D126470
2022-05-26 10:19:25 -04:00
generate-cmake -C "${MONOREPO_ROOT}/libcxx/cmake/caches/Generic-abi-unstable.cmake"
[libc++] Add Unstable ABI CI run Reviewed By: ldionne, #libc, Mordante Spies: mgorny, Mordante, libcxx-commits, arichardson Differential Revision: https://reviews.llvm.org/D118725
2022-02-05 14:09:45 +01:00
check-runtimes
;;
[libc++] Allow running the test suite with optimizations (#68753) This patch adds a configuration of the libc++ test suite that enables optimizations when building the tests. It also adds a new CI configuration to exercise this on a regular basis. This is added in the context of [1], which requires building with optimizations in order to hit the bug. [1]: https://github.com/llvm/llvm-project/issues/68552
2024-01-09 10:39:14 -05:00
generic-optimized-speed)
clean
generate-cmake -C "${MONOREPO_ROOT}/libcxx/cmake/caches/Generic-optimized-speed.cmake"
check-runtimes
;;
[libc++] Fix deployment target Lit features (#94791) We were not making any distinction between e.g. the "Apple-flavored" libc++ built from trunk and the system-provided standard library on Apple platforms. For example, any test that would be XFAILed on a back-deployment target would unexpectedly pass when run on that deployment target against the tip of trunk Apple-flavored libc++. In reality, that test would be expected to pass because we're running against the latest libc++, even if it is Apple-flavored. To solve this issue, we introduce a new feature that describes whether the Standard Library in use is the one provided by the system by default, and that notion is different from the underlying standard library flavor. We also refactor the existing Lit features to make a distinction between availability markup and the library we're running against at runtime, which otherwise limit the flexibility of what we can express in the test suite. Finally, we refactor some of the back-deployment versions that were incorrect (such as thinking that LLVM 10 was introduced in macOS 11, when in reality macOS 11 was synced with LLVM 11). Fixes #82107
2024-06-21 10:31:22 -04:00
apple-configuration)
[libc++] Allow customizing a few paths when running build bots This allows reusing run-buildbot for downstream testing as well.
2020-11-05 19:02:32 -05:00
clean
[libc++] Use apple-install-libcxx.sh in the Apple/system CI job That script is what we (need to) use to build libc++ for the system configuration, so that's what we should test against. At some point we may be able to fold all of that logic into the CMake build, and when that happens the CI can go back to running CMake directly. As a fly-by fix, stop mentioning x86_64 in the names of the Apple jobs since they are not truly tied to any architecture. Differential Revision: https://reviews.llvm.org/D111865
2021-10-15 00:21:26 -04:00
[libc++] Add output groups to run-buildbot (#111739) This improves the CI output by providing collapsable sections for sub-parts of our build. This was originally opened as #75233. Co-authored-by: eric <eric@efcs.ca>
2024-10-11 09:29:47 -04:00
step "Installing libc++ with the Apple system configuration"
[libc++] Use apple-install-libcxx.sh in the Apple/system CI job That script is what we (need to) use to build libc++ for the system configuration, so that's what we should test against. At some point we may be able to fold all of that logic into the CMake build, and when that happens the CI can go back to running CMake directly. As a fly-by fix, stop mentioning x86_64 in the names of the Apple jobs since they are not truly tied to any architecture. Differential Revision: https://reviews.llvm.org/D111865
2021-10-15 00:21:26 -04:00
arch="$(uname -m)"
[libc++] Refactor the Apple build scripts This patch upstreams some changes we've made internally to how we're building the libc++ dylib on Apple platforms. The goal is still to eventually get rid of `apple-install-libcxx.sh` entirely and have a proper way to mirror what we do internally with just the normal CMake configuration. Differential Revision: https://reviews.llvm.org/D118912
2022-02-03 10:57:49 -05:00
xcrun --sdk macosx \
${MONOREPO_ROOT}/libcxx/utils/ci/apple-install-libcxx.sh \
--llvm-root ${MONOREPO_ROOT} \
--build-dir ${BUILD_DIR} \
--install-dir ${INSTALL_DIR} \
--symbols-dir "${BUILD_DIR}/symbols" \
--architectures "${arch}" \
--version "999.99"
[libc++] Use apple-install-libcxx.sh in the Apple/system CI job That script is what we (need to) use to build libc++ for the system configuration, so that's what we should test against. At some point we may be able to fold all of that logic into the CMake build, and when that happens the CI can go back to running CMake directly. As a fly-by fix, stop mentioning x86_64 in the names of the Apple jobs since they are not truly tied to any architecture. Differential Revision: https://reviews.llvm.org/D111865
2021-10-15 00:21:26 -04:00
[libc++] Add output groups to run-buildbot (#111739) This improves the CI output by providing collapsable sections for sub-parts of our build. This was originally opened as #75233. Co-authored-by: eric <eric@efcs.ca>
2024-10-11 09:29:47 -04:00
step "Running tests against Apple-configured libc++"
[libc++] Use apple-install-libcxx.sh in the Apple/system CI job That script is what we (need to) use to build libc++ for the system configuration, so that's what we should test against. At some point we may be able to fold all of that logic into the CMake build, and when that happens the CI can go back to running CMake directly. As a fly-by fix, stop mentioning x86_64 in the names of the Apple jobs since they are not truly tied to any architecture. Differential Revision: https://reviews.llvm.org/D111865
2021-10-15 00:21:26 -04:00
# TODO: It would be better to run the tests against the fake-installed version of libc++ instead
[libc++] Take more knobs into account when generating ABI lists This change will make it possible to track exported symbols in more configurations, notably the Apple system one, where we disable incomplete features and the debug mode. Also, as a fly-by fix, shorten the name for whether new is in libc++ or not. Differential Revision: https://reviews.llvm.org/D119764
2022-02-14 14:39:17 -05:00
xcrun --sdk macosx ninja -vC "${BUILD_DIR}/${arch}" check-cxx check-cxxabi check-cxx-abilist
[libc++][ci] Add a configuration testing Apple's system library build Differential Revision: https://reviews.llvm.org/D88650
2020-10-01 08:55:40 -04:00
;;
[runtimes] Run backdeployment CI on Github hosted runners (#109984) This removes the need for macOS nodes in Buildkite. It also moves to the proper way of testing backdeployment, which is to actually run on the target OS itself, instead of using packaged dylibs from previous OS versions and trying to emulate backdeployment with DYLD_LIBRARY_PATH. As a drive-by change, also fix a few back-deployment annotations that were incorrect and add support for minor versions in the Lit feature determining availability from the target triple.
2024-09-30 17:08:44 -04:00
apple-system-hardened)
[libc++] Allow enabling assertions when back-deploying When back-deploying to older platforms, we can still provide assertions, but we might not be able to provide a great implementation for the verbose handler. Instead, we can just call ::abort(). Differential Revision: https://reviews.llvm.org/D131199
2022-08-04 15:25:48 -04:00
clean
[runtimes] Run backdeployment CI on Github hosted runners (#109984) This removes the need for macOS nodes in Buildkite. It also moves to the proper way of testing backdeployment, which is to actually run on the target OS itself, instead of using packaged dylibs from previous OS versions and trying to emulate backdeployment with DYLD_LIBRARY_PATH. As a drive-by change, also fix a few back-deployment annotations that were incorrect and add support for minor versions in the Lit feature determining availability from the target triple.
2024-09-30 17:08:44 -04:00
arch="$(uname -m)"
version="$(sw_vers --productVersion)"
params="target_triple=${arch}-apple-macosx${version}"
params+=";hardening_mode=fast"
[libc++] Allow enabling assertions when back-deploying When back-deploying to older platforms, we can still provide assertions, but we might not be able to provide a great implementation for the verbose handler. Instead, we can just call ::abort(). Differential Revision: https://reviews.llvm.org/D131199
2022-08-04 15:25:48 -04:00
[runtimes] Run backdeployment CI on Github hosted runners (#109984) This removes the need for macOS nodes in Buildkite. It also moves to the proper way of testing backdeployment, which is to actually run on the target OS itself, instead of using packaged dylibs from previous OS versions and trying to emulate backdeployment with DYLD_LIBRARY_PATH. As a drive-by change, also fix a few back-deployment annotations that were incorrect and add support for minor versions in the Lit feature determining availability from the target triple.
2024-09-30 17:08:44 -04:00
# In the Apple system configuration, we build libc++ and libunwind separately.
[libc++] Add output groups to run-buildbot (#111739) This improves the CI output by providing collapsable sections for sub-parts of our build. This was originally opened as #75233. Co-authored-by: eric <eric@efcs.ca>
2024-10-11 09:29:47 -04:00
step "Installing libc++ and libc++abi in Apple-system configuration"
[runtimes] Run backdeployment CI on Github hosted runners (#109984) This removes the need for macOS nodes in Buildkite. It also moves to the proper way of testing backdeployment, which is to actually run on the target OS itself, instead of using packaged dylibs from previous OS versions and trying to emulate backdeployment with DYLD_LIBRARY_PATH. As a drive-by change, also fix a few back-deployment annotations that were incorrect and add support for minor versions in the Lit feature determining availability from the target triple.
2024-09-30 17:08:44 -04:00
${CMAKE} \
-S "${MONOREPO_ROOT}/runtimes" \
-B "${BUILD_DIR}/cxx" \
-GNinja -DCMAKE_MAKE_PROGRAM="${NINJA}" \
-DCMAKE_BUILD_TYPE=RelWithDebInfo \
-DCMAKE_INSTALL_PREFIX="${INSTALL_DIR}/cxx" \
-DLLVM_LIT_ARGS="-sv --xunit-xml-output test-results.xml --timeout=1500 --time-tests" \
-DLLVM_ENABLE_RUNTIMES="libcxx;libcxxabi" \
-DLIBCXX_CXX_ABI=libcxxabi \
-C "${MONOREPO_ROOT}/libcxx/cmake/caches/Apple.cmake" \
-DLIBCXX_TEST_CONFIG="apple-libc++-system.cfg.in" \
-DLIBCXXABI_TEST_CONFIG="apple-libc++abi-system.cfg.in" \
-DLIBCXX_TEST_PARAMS="${params}" \
-DLIBCXXABI_TEST_PARAMS="${params}"
[libc++] Allow enabling assertions when back-deploying When back-deploying to older platforms, we can still provide assertions, but we might not be able to provide a great implementation for the verbose handler. Instead, we can just call ::abort(). Differential Revision: https://reviews.llvm.org/D131199
2022-08-04 15:25:48 -04:00
[libc++] Add output groups to run-buildbot (#111739) This improves the CI output by providing collapsable sections for sub-parts of our build. This was originally opened as #75233. Co-authored-by: eric <eric@efcs.ca>
2024-10-11 09:29:47 -04:00
step "Installing libunwind in Apple-system configuration"
[runtimes] Run backdeployment CI on Github hosted runners (#109984) This removes the need for macOS nodes in Buildkite. It also moves to the proper way of testing backdeployment, which is to actually run on the target OS itself, instead of using packaged dylibs from previous OS versions and trying to emulate backdeployment with DYLD_LIBRARY_PATH. As a drive-by change, also fix a few back-deployment annotations that were incorrect and add support for minor versions in the Lit feature determining availability from the target triple.
2024-09-30 17:08:44 -04:00
${CMAKE} \
-S "${MONOREPO_ROOT}/runtimes" \
-B "${BUILD_DIR}/unwind" \
-GNinja -DCMAKE_MAKE_PROGRAM="${NINJA}" \
-DCMAKE_BUILD_TYPE=RelWithDebInfo \
-DCMAKE_INSTALL_PREFIX="${INSTALL_DIR}/unwind" \
-DLLVM_LIT_ARGS="-sv --xunit-xml-output test-results.xml --timeout=1500 --time-tests" \
-DLLVM_ENABLE_RUNTIMES="libunwind" \
-DLIBUNWIND_TEST_CONFIG="apple-libunwind-system.cfg.in" \
-DLIBUNWIND_TEST_PARAMS="${params}" \
-DCMAKE_INSTALL_NAME_DIR="/usr/lib/system"
[libc++] Allow enabling assertions when back-deploying When back-deploying to older platforms, we can still provide assertions, but we might not be able to provide a great implementation for the verbose handler. Instead, we can just call ::abort(). Differential Revision: https://reviews.llvm.org/D131199
2022-08-04 15:25:48 -04:00
[libc++] Add output groups to run-buildbot (#111739) This improves the CI output by providing collapsable sections for sub-parts of our build. This was originally opened as #75233. Co-authored-by: eric <eric@efcs.ca>
2024-10-11 09:29:47 -04:00
step "Running the libc++ tests"
[runtimes] Run backdeployment CI on Github hosted runners (#109984) This removes the need for macOS nodes in Buildkite. It also moves to the proper way of testing backdeployment, which is to actually run on the target OS itself, instead of using packaged dylibs from previous OS versions and trying to emulate backdeployment with DYLD_LIBRARY_PATH. As a drive-by change, also fix a few back-deployment annotations that were incorrect and add support for minor versions in the Lit feature determining availability from the target triple.
2024-09-30 17:08:44 -04:00
${NINJA} -vC "${BUILD_DIR}/cxx" check-cxx
[libc++] Allow enabling assertions when back-deploying When back-deploying to older platforms, we can still provide assertions, but we might not be able to provide a great implementation for the verbose handler. Instead, we can just call ::abort(). Differential Revision: https://reviews.llvm.org/D131199
2022-08-04 15:25:48 -04:00
[libc++] Add output groups to run-buildbot (#111739) This improves the CI output by providing collapsable sections for sub-parts of our build. This was originally opened as #75233. Co-authored-by: eric <eric@efcs.ca>
2024-10-11 09:29:47 -04:00
step "Running the libc++abi tests"
[runtimes] Run backdeployment CI on Github hosted runners (#109984) This removes the need for macOS nodes in Buildkite. It also moves to the proper way of testing backdeployment, which is to actually run on the target OS itself, instead of using packaged dylibs from previous OS versions and trying to emulate backdeployment with DYLD_LIBRARY_PATH. As a drive-by change, also fix a few back-deployment annotations that were incorrect and add support for minor versions in the Lit feature determining availability from the target triple.
2024-09-30 17:08:44 -04:00
${NINJA} -vC "${BUILD_DIR}/cxx" check-cxxabi
[libc++] Allow enabling assertions when back-deploying When back-deploying to older platforms, we can still provide assertions, but we might not be able to provide a great implementation for the verbose handler. Instead, we can just call ::abort(). Differential Revision: https://reviews.llvm.org/D131199
2022-08-04 15:25:48 -04:00
[libc++] Add output groups to run-buildbot (#111739) This improves the CI output by providing collapsable sections for sub-parts of our build. This was originally opened as #75233. Co-authored-by: eric <eric@efcs.ca>
2024-10-11 09:29:47 -04:00
step "Running the libunwind tests"
[runtimes] Run backdeployment CI on Github hosted runners (#109984) This removes the need for macOS nodes in Buildkite. It also moves to the proper way of testing backdeployment, which is to actually run on the target OS itself, instead of using packaged dylibs from previous OS versions and trying to emulate backdeployment with DYLD_LIBRARY_PATH. As a drive-by change, also fix a few back-deployment annotations that were incorrect and add support for minor versions in the Lit feature determining availability from the target triple.
2024-09-30 17:08:44 -04:00
${NINJA} -vC "${BUILD_DIR}/unwind" check-unwind
[libc++] Allow enabling assertions when back-deploying When back-deploying to older platforms, we can still provide assertions, but we might not be able to provide a great implementation for the verbose handler. Instead, we can just call ::abort(). Differential Revision: https://reviews.llvm.org/D131199
2022-08-04 15:25:48 -04:00
;;
[runtimes] Run backdeployment CI on Github hosted runners (#109984) This removes the need for macOS nodes in Buildkite. It also moves to the proper way of testing backdeployment, which is to actually run on the target OS itself, instead of using packaged dylibs from previous OS versions and trying to emulate backdeployment with DYLD_LIBRARY_PATH. As a drive-by change, also fix a few back-deployment annotations that were incorrect and add support for minor versions in the Lit feature determining availability from the target triple.
2024-09-30 17:08:44 -04:00
apple-system)
[libc++] Allow customizing a few paths when running build bots This allows reusing run-buildbot for downstream testing as well.
2020-11-05 19:02:32 -05:00
clean
[runtimes] Run backdeployment CI on Github hosted runners (#109984) This removes the need for macOS nodes in Buildkite. It also moves to the proper way of testing backdeployment, which is to actually run on the target OS itself, instead of using packaged dylibs from previous OS versions and trying to emulate backdeployment with DYLD_LIBRARY_PATH. As a drive-by change, also fix a few back-deployment annotations that were incorrect and add support for minor versions in the Lit feature determining availability from the target triple.
2024-09-30 17:08:44 -04:00
arch="$(uname -m)"
version="$(sw_vers --productVersion)"
params="target_triple=${arch}-apple-macosx${version}"
[libc++] Allow customizing a few paths when running build bots This allows reusing run-buildbot for downstream testing as well.
2020-11-05 19:02:32 -05:00
[runtimes] Run backdeployment CI on Github hosted runners (#109984) This removes the need for macOS nodes in Buildkite. It also moves to the proper way of testing backdeployment, which is to actually run on the target OS itself, instead of using packaged dylibs from previous OS versions and trying to emulate backdeployment with DYLD_LIBRARY_PATH. As a drive-by change, also fix a few back-deployment annotations that were incorrect and add support for minor versions in the Lit feature determining availability from the target triple.
2024-09-30 17:08:44 -04:00
# In the Apple system configuration, we build libc++ and libunwind separately.
[libc++] Add output groups to run-buildbot (#111739) This improves the CI output by providing collapsable sections for sub-parts of our build. This was originally opened as #75233. Co-authored-by: eric <eric@efcs.ca>
2024-10-11 09:29:47 -04:00
step "Installing libc++ and libc++abi in Apple-system configuration"
[runtimes] Run backdeployment CI on Github hosted runners (#109984) This removes the need for macOS nodes in Buildkite. It also moves to the proper way of testing backdeployment, which is to actually run on the target OS itself, instead of using packaged dylibs from previous OS versions and trying to emulate backdeployment with DYLD_LIBRARY_PATH. As a drive-by change, also fix a few back-deployment annotations that were incorrect and add support for minor versions in the Lit feature determining availability from the target triple.
2024-09-30 17:08:44 -04:00
${CMAKE} \
-S "${MONOREPO_ROOT}/runtimes" \
-B "${BUILD_DIR}/cxx" \
-GNinja -DCMAKE_MAKE_PROGRAM="${NINJA}" \
-DCMAKE_BUILD_TYPE=RelWithDebInfo \
-DCMAKE_INSTALL_PREFIX="${INSTALL_DIR}/cxx" \
-DLLVM_LIT_ARGS="-sv --xunit-xml-output test-results.xml --timeout=1500 --time-tests" \
-DLLVM_ENABLE_RUNTIMES="libcxx;libcxxabi" \
-DLIBCXX_CXX_ABI=libcxxabi \
-C "${MONOREPO_ROOT}/libcxx/cmake/caches/Apple.cmake" \
-DLIBCXX_TEST_CONFIG="apple-libc++-system.cfg.in" \
-DLIBCXXABI_TEST_CONFIG="apple-libc++abi-system.cfg.in" \
-DLIBCXX_TEST_PARAMS="${params}" \
-DLIBCXXABI_TEST_PARAMS="${params}"
[libc++/abi] Allow running back-deployment testing against libc++abi Before this patch, we could only link against the back-deployment libc++abi dylib. This patch allows linking against the just-built libc++abi, but running against the back-deployment one -- just like we do for libc++. Also, add XFAIL markup to flag expected errors. Differential Revision: https://reviews.llvm.org/D91069
2020-07-08 16:38:54 -04:00
[libc++] Add output groups to run-buildbot (#111739) This improves the CI output by providing collapsable sections for sub-parts of our build. This was originally opened as #75233. Co-authored-by: eric <eric@efcs.ca>
2024-10-11 09:29:47 -04:00
step "Installing libunwind in Apple-system configuration"
[runtimes] Run backdeployment CI on Github hosted runners (#109984) This removes the need for macOS nodes in Buildkite. It also moves to the proper way of testing backdeployment, which is to actually run on the target OS itself, instead of using packaged dylibs from previous OS versions and trying to emulate backdeployment with DYLD_LIBRARY_PATH. As a drive-by change, also fix a few back-deployment annotations that were incorrect and add support for minor versions in the Lit feature determining availability from the target triple.
2024-09-30 17:08:44 -04:00
${CMAKE} \
-S "${MONOREPO_ROOT}/runtimes" \
-B "${BUILD_DIR}/unwind" \
-GNinja -DCMAKE_MAKE_PROGRAM="${NINJA}" \
-DCMAKE_BUILD_TYPE=RelWithDebInfo \
-DCMAKE_INSTALL_PREFIX="${INSTALL_DIR}/unwind" \
-DLLVM_LIT_ARGS="-sv --xunit-xml-output test-results.xml --timeout=1500 --time-tests" \
-DLLVM_ENABLE_RUNTIMES="libunwind" \
-DLIBUNWIND_TEST_CONFIG="apple-libunwind-system.cfg.in" \
-DLIBUNWIND_TEST_PARAMS="${params}" \
-DCMAKE_INSTALL_NAME_DIR="/usr/lib/system"
[libc++/abi] Allow running back-deployment testing against libc++abi Before this patch, we could only link against the back-deployment libc++abi dylib. This patch allows linking against the just-built libc++abi, but running against the back-deployment one -- just like we do for libc++. Also, add XFAIL markup to flag expected errors. Differential Revision: https://reviews.llvm.org/D91069
2020-07-08 16:38:54 -04:00
[libc++] Add output groups to run-buildbot (#111739) This improves the CI output by providing collapsable sections for sub-parts of our build. This was originally opened as #75233. Co-authored-by: eric <eric@efcs.ca>
2024-10-11 09:29:47 -04:00
step "Running the libc++ tests"
[runtimes] Run backdeployment CI on Github hosted runners (#109984) This removes the need for macOS nodes in Buildkite. It also moves to the proper way of testing backdeployment, which is to actually run on the target OS itself, instead of using packaged dylibs from previous OS versions and trying to emulate backdeployment with DYLD_LIBRARY_PATH. As a drive-by change, also fix a few back-deployment annotations that were incorrect and add support for minor versions in the Lit feature determining availability from the target triple.
2024-09-30 17:08:44 -04:00
${NINJA} -vC "${BUILD_DIR}/cxx" check-cxx
[libc++] Allow customizing a few paths when running build bots This allows reusing run-buildbot for downstream testing as well.
2020-11-05 19:02:32 -05:00
[libc++] Add output groups to run-buildbot (#111739) This improves the CI output by providing collapsable sections for sub-parts of our build. This was originally opened as #75233. Co-authored-by: eric <eric@efcs.ca>
2024-10-11 09:29:47 -04:00
step "Running the libc++abi tests"
[runtimes] Run backdeployment CI on Github hosted runners (#109984) This removes the need for macOS nodes in Buildkite. It also moves to the proper way of testing backdeployment, which is to actually run on the target OS itself, instead of using packaged dylibs from previous OS versions and trying to emulate backdeployment with DYLD_LIBRARY_PATH. As a drive-by change, also fix a few back-deployment annotations that were incorrect and add support for minor versions in the Lit feature determining availability from the target triple.
2024-09-30 17:08:44 -04:00
${NINJA} -vC "${BUILD_DIR}/cxx" check-cxxabi
[libc++] Allow customizing a few paths when running build bots This allows reusing run-buildbot for downstream testing as well.
2020-11-05 19:02:32 -05:00
[libc++] Add output groups to run-buildbot (#111739) This improves the CI output by providing collapsable sections for sub-parts of our build. This was originally opened as #75233. Co-authored-by: eric <eric@efcs.ca>
2024-10-11 09:29:47 -04:00
step "Running the libunwind tests"
[runtimes] Run backdeployment CI on Github hosted runners (#109984) This removes the need for macOS nodes in Buildkite. It also moves to the proper way of testing backdeployment, which is to actually run on the target OS itself, instead of using packaged dylibs from previous OS versions and trying to emulate backdeployment with DYLD_LIBRARY_PATH. As a drive-by change, also fix a few back-deployment annotations that were incorrect and add support for minor versions in the Lit feature determining availability from the target triple.
2024-09-30 17:08:44 -04:00
${NINJA} -vC "${BUILD_DIR}/unwind" check-unwind
[libc++] Add a Buildkite job that tests back-deployment on Apple The current way we test this is pretty cheap, i.e. we download previously released macOS dylibs and run against that. Ideally, we would require a full host running the appropriate version of macOS, and we'd execute the tests using SSH on that host. But since we don't have such hosts available easily for now, this is better than nothing. At the same time, also fix some tests that were failing when back deploying. Differential Revision: https://reviews.llvm.org/D90869
2020-11-05 10:47:06 -05:00
;;
[libcxx] Move Linaro AArch64 buildbots to buildkite Reviewed By: #libc, ldionne Differential Revision: https://reviews.llvm.org/D96267
2021-02-08 10:43:21 +00:00
aarch64)
clean
[libunwind] Tidy-up the testing configuration for libunwind Start testing Apple backdeployment with older libunwinds, and stop explicitly specifying the libunwind testing config, since it is already selected correctly by default. Differential Revision: https://reviews.llvm.org/D126470
2022-05-26 10:19:25 -04:00
generate-cmake -C "${MONOREPO_ROOT}/libcxx/cmake/caches/AArch64.cmake"
[runtimes][ci] Run the tests for libunwind in the CI We should arguably have always been doing that. The state of libunwind is quite sad, so this commit adds several XFAILs to make the CI pass. We need to investigate why so many tests are not passing in some configurations, but I'll defer that to folks who actually work on libunwind for lack of bandwidth. Differential Revision: https://reviews.llvm.org/D110872
2021-09-30 15:11:48 -04:00
check-runtimes
[libcxx] Move Linaro AArch64 buildbots to buildkite Reviewed By: #libc, ldionne Differential Revision: https://reviews.llvm.org/D96267
2021-02-08 10:43:21 +00:00
;;
[libc++][NFC] Rename the 'noexceptions' CI config to 'no-exceptions' for consistency Differential Revision: https://reviews.llvm.org/D150672
2023-05-16 07:48:13 -07:00
aarch64-no-exceptions)
[libcxx] Move Linaro AArch64 buildbots to buildkite Reviewed By: #libc, ldionne Differential Revision: https://reviews.llvm.org/D96267
2021-02-08 10:43:21 +00:00
clean
generate-cmake -C "${MONOREPO_ROOT}/libcxx/cmake/caches/AArch64.cmake" \
[libc++] NFC: Reindent the run-buildbot script
2021-07-15 13:29:47 -04:00
-DLIBCXX_ENABLE_EXCEPTIONS=OFF \
[libunwind] Tidy-up the testing configuration for libunwind Start testing Apple backdeployment with older libunwinds, and stop explicitly specifying the libunwind testing config, since it is already selected correctly by default. Differential Revision: https://reviews.llvm.org/D126470
2022-05-26 10:19:25 -04:00
-DLIBCXXABI_ENABLE_EXCEPTIONS=OFF
[runtimes][ci] Run the tests for libunwind in the CI We should arguably have always been doing that. The state of libunwind is quite sad, so this commit adds several XFAILs to make the CI pass. We need to investigate why so many tests are not passing in some configurations, but I'll defer that to folks who actually work on libunwind for lack of bandwidth. Differential Revision: https://reviews.llvm.org/D110872
2021-09-30 15:11:48 -04:00
check-runtimes
[libcxx] Move Linaro AArch64 buildbots to buildkite Reviewed By: #libc, ldionne Differential Revision: https://reviews.llvm.org/D96267
2021-02-08 10:43:21 +00:00
;;
[libcxx] Move Linaro 32 bit armv bots to buildkite Instead of setting mcpu like the previous bots, set the target triple. Each config builds either Arm only or Thumb only code. This gives us some coverage of thumb specific issues. The new agents on Linaro's side are running on v8 hardware so will report arch "armv8l" just like the v8 bots. (and buildkite can choose any of them for v7/v8 jobs) Reviewed By: #libc, curdeius, Mordante Differential Revision: https://reviews.llvm.org/D98019
2021-03-02 15:07:19 +00:00
# Aka Armv8 32 bit
armv8)
clean
[libunwind] Tidy-up the testing configuration for libunwind Start testing Apple backdeployment with older libunwinds, and stop explicitly specifying the libunwind testing config, since it is already selected correctly by default. Differential Revision: https://reviews.llvm.org/D126470
2022-05-26 10:19:25 -04:00
generate-cmake -C "${MONOREPO_ROOT}/libcxx/cmake/caches/Armv8Arm.cmake"
[runtimes][ci] Run the tests for libunwind in the CI We should arguably have always been doing that. The state of libunwind is quite sad, so this commit adds several XFAILs to make the CI pass. We need to investigate why so many tests are not passing in some configurations, but I'll defer that to folks who actually work on libunwind for lack of bandwidth. Differential Revision: https://reviews.llvm.org/D110872
2021-09-30 15:11:48 -04:00
check-runtimes
[libcxx] Move Linaro 32 bit armv bots to buildkite Instead of setting mcpu like the previous bots, set the target triple. Each config builds either Arm only or Thumb only code. This gives us some coverage of thumb specific issues. The new agents on Linaro's side are running on v8 hardware so will report arch "armv8l" just like the v8 bots. (and buildkite can choose any of them for v7/v8 jobs) Reviewed By: #libc, curdeius, Mordante Differential Revision: https://reviews.llvm.org/D98019
2021-03-02 15:07:19 +00:00
;;
[libc++][NFC] Rename the 'noexceptions' CI config to 'no-exceptions' for consistency Differential Revision: https://reviews.llvm.org/D150672
2023-05-16 07:48:13 -07:00
armv8-no-exceptions)
[libcxx] Move Linaro 32 bit armv bots to buildkite Instead of setting mcpu like the previous bots, set the target triple. Each config builds either Arm only or Thumb only code. This gives us some coverage of thumb specific issues. The new agents on Linaro's side are running on v8 hardware so will report arch "armv8l" just like the v8 bots. (and buildkite can choose any of them for v7/v8 jobs) Reviewed By: #libc, curdeius, Mordante Differential Revision: https://reviews.llvm.org/D98019
2021-03-02 15:07:19 +00:00
clean
[libc++][NFC] Rename the 'noexceptions' CI config to 'no-exceptions' for consistency Differential Revision: https://reviews.llvm.org/D150672
2023-05-16 07:48:13 -07:00
generate-cmake -C "${MONOREPO_ROOT}/libcxx/cmake/caches/Armv8Thumb-no-exceptions.cmake"
[runtimes][ci] Run the tests for libunwind in the CI We should arguably have always been doing that. The state of libunwind is quite sad, so this commit adds several XFAILs to make the CI pass. We need to investigate why so many tests are not passing in some configurations, but I'll defer that to folks who actually work on libunwind for lack of bandwidth. Differential Revision: https://reviews.llvm.org/D110872
2021-09-30 15:11:48 -04:00
check-runtimes
[libcxx] Move Linaro 32 bit armv bots to buildkite Instead of setting mcpu like the previous bots, set the target triple. Each config builds either Arm only or Thumb only code. This gives us some coverage of thumb specific issues. The new agents on Linaro's side are running on v8 hardware so will report arch "armv8l" just like the v8 bots. (and buildkite can choose any of them for v7/v8 jobs) Reviewed By: #libc, curdeius, Mordante Differential Revision: https://reviews.llvm.org/D98019
2021-03-02 15:07:19 +00:00
;;
# Armv7 32 bit. One building Arm only one Thumb only code.
armv7)
clean
[libunwind] Tidy-up the testing configuration for libunwind Start testing Apple backdeployment with older libunwinds, and stop explicitly specifying the libunwind testing config, since it is already selected correctly by default. Differential Revision: https://reviews.llvm.org/D126470
2022-05-26 10:19:25 -04:00
generate-cmake -C "${MONOREPO_ROOT}/libcxx/cmake/caches/Armv7Arm.cmake"
[runtimes][ci] Run the tests for libunwind in the CI We should arguably have always been doing that. The state of libunwind is quite sad, so this commit adds several XFAILs to make the CI pass. We need to investigate why so many tests are not passing in some configurations, but I'll defer that to folks who actually work on libunwind for lack of bandwidth. Differential Revision: https://reviews.llvm.org/D110872
2021-09-30 15:11:48 -04:00
check-runtimes
[libcxx] Move Linaro 32 bit armv bots to buildkite Instead of setting mcpu like the previous bots, set the target triple. Each config builds either Arm only or Thumb only code. This gives us some coverage of thumb specific issues. The new agents on Linaro's side are running on v8 hardware so will report arch "armv8l" just like the v8 bots. (and buildkite can choose any of them for v7/v8 jobs) Reviewed By: #libc, curdeius, Mordante Differential Revision: https://reviews.llvm.org/D98019
2021-03-02 15:07:19 +00:00
;;
[libc++][NFC] Rename the 'noexceptions' CI config to 'no-exceptions' for consistency Differential Revision: https://reviews.llvm.org/D150672
2023-05-16 07:48:13 -07:00
armv7-no-exceptions)
[libcxx] Move Linaro 32 bit armv bots to buildkite Instead of setting mcpu like the previous bots, set the target triple. Each config builds either Arm only or Thumb only code. This gives us some coverage of thumb specific issues. The new agents on Linaro's side are running on v8 hardware so will report arch "armv8l" just like the v8 bots. (and buildkite can choose any of them for v7/v8 jobs) Reviewed By: #libc, curdeius, Mordante Differential Revision: https://reviews.llvm.org/D98019
2021-03-02 15:07:19 +00:00
clean
[libc++][NFC] Rename the 'noexceptions' CI config to 'no-exceptions' for consistency Differential Revision: https://reviews.llvm.org/D150672
2023-05-16 07:48:13 -07:00
generate-cmake -C "${MONOREPO_ROOT}/libcxx/cmake/caches/Armv7Thumb-no-exceptions.cmake"
[runtimes][ci] Run the tests for libunwind in the CI We should arguably have always been doing that. The state of libunwind is quite sad, so this commit adds several XFAILs to make the CI pass. We need to investigate why so many tests are not passing in some configurations, but I'll defer that to folks who actually work on libunwind for lack of bandwidth. Differential Revision: https://reviews.llvm.org/D110872
2021-09-30 15:11:48 -04:00
check-runtimes
[libc++] Add initial support for picolibc Picolibc is a C Standard Library that is commonly used in embedded environments. This patch adds initial support for this configuration along with pre-commit CI. As of this patch, the test suite only builds the tests and nothing is run. A follow-up patch will make the test suite actually run the tests. Differential Revision: https://reviews.llvm.org/D154246
2023-11-29 09:56:20 -05:00
;;
armv7m-picolibc)
[libc++] Add a picolibc test configuration with exceptions enabled (#75462)
2023-12-18 16:25:50 +01:00
test-armv7m-picolibc \
-C "${MONOREPO_ROOT}/libcxx/cmake/caches/Armv7M-picolibc.cmake"
;;
armv7m-picolibc-no-exceptions)
test-armv7m-picolibc \
[libc++] Add initial support for picolibc Picolibc is a C Standard Library that is commonly used in embedded environments. This patch adds initial support for this configuration along with pre-commit CI. As of this patch, the test suite only builds the tests and nothing is run. A follow-up patch will make the test suite actually run the tests. Differential Revision: https://reviews.llvm.org/D154246
2023-11-29 09:56:20 -05:00
-C "${MONOREPO_ROOT}/libcxx/cmake/caches/Armv7M-picolibc.cmake" \
[libc++] Add a picolibc test configuration with exceptions enabled (#75462)
2023-12-18 16:25:50 +01:00
-DLIBCXXABI_ENABLE_EXCEPTIONS=OFF \
-DLIBCXXABI_ENABLE_STATIC_UNWINDER=OFF \
-DLIBCXX_ENABLE_EXCEPTIONS=OFF \
-DLIBCXX_ENABLE_RTTI=OFF
[libcxx] Move Linaro 32 bit armv bots to buildkite Instead of setting mcpu like the previous bots, set the target triple. Each config builds either Arm only or Thumb only code. This gives us some coverage of thumb specific issues. The new agents on Linaro's side are running on v8 hardware so will report arch "armv8l" just like the v8 bots. (and buildkite can choose any of them for v7/v8 jobs) Reviewed By: #libc, curdeius, Mordante Differential Revision: https://reviews.llvm.org/D98019
2021-03-02 15:07:19 +00:00
;;
[libcxx] [ci] Add CI configurations for MinGW Mention support for MinGW in the docs. Rename the existing windows CI jobs to Clang-cl, as both Clang-cl and MinGW are equally much "Windows", just different toolchain environments. Add an XFAIL for a recently added test that fails in the MinGW DLL configuration (with an explanation of what's causing the failure). Differential Revision: https://reviews.llvm.org/D112215
2021-10-01 23:08:57 +03:00
clang-cl-dll)
[libcxx] [ci] Add a Windows CI buildkite configuration Differential Revision: https://reviews.llvm.org/D99093
2021-03-17 12:10:42 +02:00
clean
# TODO: Currently, building with the experimental library breaks running
# tests (the test linking look for the c++experimental library with the
# wrong name, and the statically linked c++experimental can't be linked
# correctly when libc++ visibility attributes indicate dllimport linkage
# anyway), thus just disable the experimental library. Remove this
# setting when cmake and the test driver does the right thing automatically.
[libc++] Re-apply "Always build c++experimental.a"" This re-applies bb939931a1ad, which had been reverted by 09cebfb978de because it broke Chromium. The issues seen by Chromium should be addressed by 1d0f79558ca4. Differential Revision: https://reviews.llvm.org/D128927
2022-07-19 10:44:06 -04:00
generate-cmake-libcxx-win -DLIBCXX_TEST_PARAMS="enable_experimental=False"
[libc++] Add output groups to run-buildbot (#111739) This improves the CI output by providing collapsable sections for sub-parts of our build. This was originally opened as #75233. Co-authored-by: eric <eric@efcs.ca>
2024-10-11 09:29:47 -04:00
step "Running the libc++ tests"
[libcxx] [ci] Add a Windows CI configuration for a statically linked libc++ On Windows, static vs DLL linking affects details in quite a few cases, so it's good to have coverage for both cases. Testing with static linking also increases coverage for a number of cases and individual checks that have had to be waived for the DLL case, and allows testing libc++experimental, increasing the number of test cases actually executed by 180 (176 new tests from libc++experimental and 4 ones that are XFAIL windows-dll). Also drop the "generic-" prefix from these configuration names, as they're perhaps not what the "generic" prefix intended originally in the other generic-posix configurations. Differential Revision: https://reviews.llvm.org/D101565
2021-04-06 00:17:30 +03:00
${NINJA} -vC "${BUILD_DIR}" check-cxx
;;
[libcxx] [ci] Add CI configurations for MinGW Mention support for MinGW in the docs. Rename the existing windows CI jobs to Clang-cl, as both Clang-cl and MinGW are equally much "Windows", just different toolchain environments. Add an XFAIL for a recently added test that fails in the MinGW DLL configuration (with an explanation of what's causing the failure). Differential Revision: https://reviews.llvm.org/D112215
2021-10-01 23:08:57 +03:00
clang-cl-static)
[libcxx] [ci] Add a Windows CI configuration for a statically linked libc++ On Windows, static vs DLL linking affects details in quite a few cases, so it's good to have coverage for both cases. Testing with static linking also increases coverage for a number of cases and individual checks that have had to be waived for the DLL case, and allows testing libc++experimental, increasing the number of test cases actually executed by 180 (176 new tests from libc++experimental and 4 ones that are XFAIL windows-dll). Also drop the "generic-" prefix from these configuration names, as they're perhaps not what the "generic" prefix intended originally in the other generic-posix configurations. Differential Revision: https://reviews.llvm.org/D101565
2021-04-06 00:17:30 +03:00
clean
[libc++] Switch to the new testing configurations by default We've been meaning to remove support for the legacy testing configuration for a long time. This patch switches the default from the legacy config to the appropriate new-style configuration based on a few hints. We've been running with the new-style configuration for more than a year in our CI, however it's possible that this will uncover issues with some users that run the tests on platforms that we don't support yet with the new-style configs. Unfortunately, there is no way to know about it other than to land this patch and see whether anything breaks. Differential Revision: https://reviews.llvm.org/D121632
2022-03-14 14:23:38 -04:00
generate-cmake-libcxx-win -DLIBCXX_ENABLE_SHARED=OFF
[libc++] Add output groups to run-buildbot (#111739) This improves the CI output by providing collapsable sections for sub-parts of our build. This was originally opened as #75233. Co-authored-by: eric <eric@efcs.ca>
2024-10-11 09:29:47 -04:00
step "Running the libc++ tests"
[libcxx] [ci] Add a Windows CI buildkite configuration Differential Revision: https://reviews.llvm.org/D99093
2021-03-17 12:10:42 +02:00
${NINJA} -vC "${BUILD_DIR}" check-cxx
[libcxx] [ci] Add CI configurations for MinGW Mention support for MinGW in the docs. Rename the existing windows CI jobs to Clang-cl, as both Clang-cl and MinGW are equally much "Windows", just different toolchain environments. Add an XFAIL for a recently added test that fails in the MinGW DLL configuration (with an explanation of what's causing the failure). Differential Revision: https://reviews.llvm.org/D112215
2021-10-01 23:08:57 +03:00
;;
[libcxx] Fix using the vcruntime ABI with _HAS_EXCEPTIONS=0 defined _HAS_EXCEPTIONS=0 allows disabling the exception parts of the MS STL and vcruntime, and e.g. compiler-rt/lib/fuzzer sets this define (to work around issues with MS STL). If using libc++ instead of MS STL, this define previously broke the libc++ headers. If _HAS_EXCEPTIONS is set to 0, the vcruntime_exception.h header doesn't define the ABI base class std::exception. If no exceptions are going to be thrown, this probably is fine (although it also breaks using subclasses of it as regular objects that aren't thrown), but it requires ifdeffing out all subclasses of all exception/error derived objects (which are sprinkled throughout the headers). Instead, libc++ will supply an ABI compatible definition when _HAS_EXCEPTIONS is set to 0, which will make the class hierarchies complete. In this build configuration, one can still create instances of exception subclasses, and those objects will be ABI incompatible with the ones from when _HAS_EXCEPTIONS isn't defined to 0 - but one may argue that's a pathological/self-imposed problem in that case. Reviewed By: #libc, ldionne Differential Revision: https://reviews.llvm.org/D103947
2022-08-17 20:57:59 +00:00
clang-cl-no-vcruntime)
clean
# Building libc++ in the same way as in clang-cl-dll above, but running
# tests with -D_HAS_EXCEPTIONS=0, which users might set in certain
# translation units while using libc++, even if libc++ is built with
# exceptions enabled.
generate-cmake-libcxx-win -DLIBCXX_TEST_PARAMS="enable_experimental=False" \
-DLIBCXX_TEST_CONFIG="llvm-libc++-shared-no-vcruntime-clangcl.cfg.in"
[libc++] Add output groups to run-buildbot (#111739) This improves the CI output by providing collapsable sections for sub-parts of our build. This was originally opened as #75233. Co-authored-by: eric <eric@efcs.ca>
2024-10-11 09:29:47 -04:00
step "Running the libc++ tests"
[libcxx] [test] Fix running tests with Clang-cl in Debug mode When building in debug mode, the debug version of the MSVC CRT gets linked in. (This is the default in CMake in general. In the case of libcxx, we manually link the CRT though - and in debug mode, we pick the debug version of the CRT.) When building the tests, we need to use the same version of the CRT as was used for building the library. Additionally; the debug CRT defaults to pop up a dialog box when asserts fail, which blocks running tests. By including the set_windows_crt_report_mode.h helper header, we change the assert behaviour back to that of release mode - printing a message and exiting immediately. This was supported by the old libcxx test system, where support for it was added in 7e3ee09ad24cbca3ea7687c50b53be5269127fb1. When porting over to the newer test setup, this mechanism wasn't brought over (and the old test infrastructure was removed in a48f018bb7d8fadc67c08e71409c31713daa0071). Thus: In debug mode, link against the debug versions of msvcrt and msvcprt, define _DEBUG (enabling CRT debug mode code patterns), and include the set_windows_crt_report_mode.h header. Based on a patch by Andrew Ng. Linking of the debug version of the CRT can also be done by using the new -fms-runtime-lib= Clang option. However that option was added in Clang 16, and libcxx only requires Clang 15 for now; therefore doing the CRT linking entirely manually for now (just as before). Additionally, adjust set_windows_crt_report_mode.h to avoid including the body of the file when building in C mode or in C++03 mode. This fixes the following two tests: libcxx/include_as_c.sh.cpp libcxx/selftest/dsl/dsl.sh.py The former test is built in C mode. The latter tries compiling things as C++03. Some of the vcruntime headers that we include break in C++03 mode when MS CRT debug mode is enabled. Differential Revision: https://reviews.llvm.org/D155554
2023-07-14 12:16:23 +03:00
${NINJA} -vC "${BUILD_DIR}" check-cxx
;;
clang-cl-debug)
clean
generate-cmake-libcxx-win -DLIBCXX_TEST_PARAMS="enable_experimental=False" \
-DCMAKE_BUILD_TYPE=Debug
[libc++] Add output groups to run-buildbot (#111739) This improves the CI output by providing collapsable sections for sub-parts of our build. This was originally opened as #75233. Co-authored-by: eric <eric@efcs.ca>
2024-10-11 09:29:47 -04:00
step "Running the libc++ tests"
[libcxx] Allow linking against the MSVC static CRT This respects the CMAKE_MSVC_RUNTIME_LIBRARY option for selecting the right CRT to use. Add a CI configuration that tests building this way. Based on a patch by Andrew Ng. The test config files end up accumulating and duplicating a fair bit of cmake-specific logic here; if preferred, we could also add that in `libcxx/test/CMakeLists.txt` and export a few more variables to `cmake-bridge.cfg.in` instead. Differential Revision: https://reviews.llvm.org/D155560
2023-07-17 12:52:47 +03:00
${NINJA} -vC "${BUILD_DIR}" check-cxx
;;
clang-cl-static-crt)
clean
# Test linking a static libc++ with the static CRT ("MultiThreaded" denotes
# the static CRT, as opposed to "MultiThreadedDLL" which is the default).
generate-cmake-libcxx-win -DLIBCXX_ENABLE_SHARED=OFF \
-DCMAKE_MSVC_RUNTIME_LIBRARY=MultiThreaded
[libc++] Add output groups to run-buildbot (#111739) This improves the CI output by providing collapsable sections for sub-parts of our build. This was originally opened as #75233. Co-authored-by: eric <eric@efcs.ca>
2024-10-11 09:29:47 -04:00
step "Running the libc++ tests"
[libcxx] Fix using the vcruntime ABI with _HAS_EXCEPTIONS=0 defined _HAS_EXCEPTIONS=0 allows disabling the exception parts of the MS STL and vcruntime, and e.g. compiler-rt/lib/fuzzer sets this define (to work around issues with MS STL). If using libc++ instead of MS STL, this define previously broke the libc++ headers. If _HAS_EXCEPTIONS is set to 0, the vcruntime_exception.h header doesn't define the ABI base class std::exception. If no exceptions are going to be thrown, this probably is fine (although it also breaks using subclasses of it as regular objects that aren't thrown), but it requires ifdeffing out all subclasses of all exception/error derived objects (which are sprinkled throughout the headers). Instead, libc++ will supply an ABI compatible definition when _HAS_EXCEPTIONS is set to 0, which will make the class hierarchies complete. In this build configuration, one can still create instances of exception subclasses, and those objects will be ABI incompatible with the ones from when _HAS_EXCEPTIONS isn't defined to 0 - but one may argue that's a pathological/self-imposed problem in that case. Reviewed By: #libc, ldionne Differential Revision: https://reviews.llvm.org/D103947
2022-08-17 20:57:59 +00:00
${NINJA} -vC "${BUILD_DIR}" check-cxx
;;
[libcxx] [ci] Add CI configurations for MinGW Mention support for MinGW in the docs. Rename the existing windows CI jobs to Clang-cl, as both Clang-cl and MinGW are equally much "Windows", just different toolchain environments. Add an XFAIL for a recently added test that fails in the MinGW DLL configuration (with an explanation of what's causing the failure). Differential Revision: https://reviews.llvm.org/D112215
2021-10-01 23:08:57 +03:00
mingw-dll)
clean
generate-cmake \
-C "${MONOREPO_ROOT}/libcxx/cmake/caches/MinGW.cmake"
[libcxx] [ci] Run the libcxxabi and libunwind tests in mingw configurations The check-runtimes function runs check-cxx, check-cxxabi and check-unwind. Differential Revision: https://reviews.llvm.org/D148267
2023-04-05 15:25:09 +03:00
check-runtimes
[libcxx] [ci] Add CI configurations for MinGW Mention support for MinGW in the docs. Rename the existing windows CI jobs to Clang-cl, as both Clang-cl and MinGW are equally much "Windows", just different toolchain environments. Add an XFAIL for a recently added test that fails in the MinGW DLL configuration (with an explanation of what's causing the failure). Differential Revision: https://reviews.llvm.org/D112215
2021-10-01 23:08:57 +03:00
;;
mingw-static)
clean
generate-cmake \
-C "${MONOREPO_ROOT}/libcxx/cmake/caches/MinGW.cmake" \
-DLIBCXX_ENABLE_SHARED=OFF \
-DLIBUNWIND_ENABLE_SHARED=OFF
[libcxx] [ci] Run the libcxxabi and libunwind tests in mingw configurations The check-runtimes function runs check-cxx, check-cxxabi and check-unwind. Differential Revision: https://reviews.llvm.org/D148267
2023-04-05 15:25:09 +03:00
check-runtimes
[libcxx] [ci] Add a i386 Windows configuration to CI Adding a mingw based config is easy in the current CI environment (where we can just choose the different target by calling `i686-w64-mingw32-clang`), while adding a clang-cl based config would require setting up different environment variables pointing to the i386 library directory. Just adding one config (DLL) instead of exhaustively testing both (DLL and static) as very few tests would differ in practice, to keep the CI load reasonable. Differential Revision: https://reviews.llvm.org/D124991
2022-05-04 11:05:44 +03:00
;;
mingw-dll-i686)
clean
generate-cmake \
-DCMAKE_C_COMPILER=i686-w64-mingw32-clang \
-DCMAKE_CXX_COMPILER=i686-w64-mingw32-clang++ \
-C "${MONOREPO_ROOT}/libcxx/cmake/caches/MinGW.cmake"
[libcxx] [ci] Run the libcxxabi and libunwind tests in mingw configurations The check-runtimes function runs check-cxx, check-cxxabi and check-unwind. Differential Revision: https://reviews.llvm.org/D148267
2023-04-05 15:25:09 +03:00
check-runtimes
[libcxx] [ci] Add a Windows CI buildkite configuration Differential Revision: https://reviews.llvm.org/D99093
2021-03-17 12:10:42 +02:00
;;
[libc++][ci] Add a test configuration with an incomplete sysroot (#107089) When bringing up a new cross compiler from scratch, we build libunwind/libcxx in a setup where the toolchain is incomplete and unable to perform the normal linker checks; this requires a few special cases in the CMake files. We simulate that scenario by removing the libc++ headers, libunwind and libc++ libraries from the installed toolchain. We need to set CMAKE_CXX_COMPILER_WORKS since CMake fails to probe the compiler. We need to set CMAKE_CXX_COMPILER_TARGET, since LLVM's heuristics fail when CMake hasn't been able to probe the environment properly. (This is normal; one has to set those options when setting up such a toolchain from scratch.) This adds CI coverage for these build scenarios, which otherwise seldom are tested by some build flow (but are essential when setting up a cross compiler from scratch).
2024-09-05 17:25:41 +03:00
mingw-incomplete-sysroot)
# When bringing up a new cross compiler from scratch, we build
# libunwind/libcxx in a setup where the toolchain is incomplete and
# unable to perform the normal linker checks; this requires a few
# special cases in the CMake files.
#
# Building in an incomplete setup requires setting CMAKE_*_COMPILER_WORKS,
# as CMake fails to probe the compiler. This case also requires
# setting CMAKE_CXX_COMPILER_TARGET, as LLVM's heuristics for setting
# the triple fails when CMake hasn't been able to probe the environment.
# (This is what one has to do when building the initial libunwind/libcxx
# for a new toolchain.)
clean
generate-cmake \
-DCMAKE_C_COMPILER_WORKS=TRUE \
-DCMAKE_CXX_COMPILER_WORKS=TRUE \
-DCMAKE_C_COMPILER_TARGET=x86_64-w64-windows-gnu \
-DCMAKE_CXX_COMPILER_TARGET=x86_64-w64-windows-gnu \
-C "${MONOREPO_ROOT}/libcxx/cmake/caches/MinGW.cmake"
# Only test that building succeeds; there's not much extra value in running
# the tests here, as it would be equivalent to the mingw-dll config above.
[libc++] Add output groups to run-buildbot (#111739) This improves the CI output by providing collapsable sections for sub-parts of our build. This was originally opened as #75233. Co-authored-by: eric <eric@efcs.ca>
2024-10-11 09:29:47 -04:00
step "Building the runtimes"
[libc++][ci] Add a test configuration with an incomplete sysroot (#107089) When bringing up a new cross compiler from scratch, we build libunwind/libcxx in a setup where the toolchain is incomplete and unable to perform the normal linker checks; this requires a few special cases in the CMake files. We simulate that scenario by removing the libc++ headers, libunwind and libc++ libraries from the installed toolchain. We need to set CMAKE_CXX_COMPILER_WORKS since CMake fails to probe the compiler. We need to set CMAKE_CXX_COMPILER_TARGET, since LLVM's heuristics fail when CMake hasn't been able to probe the environment properly. (This is normal; one has to set those options when setting up such a toolchain from scratch.) This adds CI coverage for these build scenarios, which otherwise seldom are tested by some build flow (but are essential when setting up a cross compiler from scratch).
2024-09-05 17:25:41 +03:00
${NINJA} -vC "${BUILD_DIR}"
;;
[libc++][AIX] Add scripts and config for building with the libcxx CI infrastructure This initial change adds the AIX configuration to run-buildbot, an AIX CMake cache file, and appropriate compiler and linker flags for testing AIX to the lit "from scratch" configuration files. Either of the 32-bit or 64-bit configurations can be built by setting `OBJECT_MODE` in the build environment (as is typical for AIX). Reviewed By: ldionne, #libc, #libc_abi Differential Revision: https://reviews.llvm.org/D111244
2021-10-13 11:41:47 -04:00
aix)
clean
[libcxx][CI][AIX] Switch to LLVM_ENABLE_RUNTIMES and to the new `runtimes` top level CMakeLists.txt since the old path is now deprecated. This requires a slight adjustment of the libcxxabi CMake, since there are required macro definitions we previously got via the `llvm/CMakeList.txt` path. Reviewed By: ldionne, #libc, #libc_abi Differential Revision: https://reviews.llvm.org/D113403
2021-11-09 12:44:44 -05:00
generate-cmake -C "${MONOREPO_ROOT}/libcxx/cmake/caches/AIX.cmake" \
[libc++][AIX] Add scripts and config for building with the libcxx CI infrastructure This initial change adds the AIX configuration to run-buildbot, an AIX CMake cache file, and appropriate compiler and linker flags for testing AIX to the lit "from scratch" configuration files. Either of the 32-bit or 64-bit configurations can be built by setting `OBJECT_MODE` in the build environment (as is typical for AIX). Reviewed By: ldionne, #libc, #libc_abi Differential Revision: https://reviews.llvm.org/D111244
2021-10-13 11:41:47 -04:00
-DLIBCXX_TEST_CONFIG="ibm-libc++-shared.cfg.in" \
[libcxx][CI][AIX] Switch to LLVM_ENABLE_RUNTIMES and to the new `runtimes` top level CMakeLists.txt since the old path is now deprecated. This requires a slight adjustment of the libcxxabi CMake, since there are required macro definitions we previously got via the `llvm/CMakeList.txt` path. Reviewed By: ldionne, #libc, #libc_abi Differential Revision: https://reviews.llvm.org/D113403
2021-11-09 12:44:44 -05:00
-DLIBCXXABI_TEST_CONFIG="ibm-libc++abi-shared.cfg.in" \
[libunwind][ci][AIX] Add libunwind to buildbot CI Summary: This patch changes scripts to add libunwind CI on AIX. Test config file ibm-libunwind-shared.cfg.in is introduced for testing on AIX. Reviewed by: ldionne, MaskRay, libunwind, ibc++abi Differential Revision: https://reviews.llvm.org/D126017
2022-06-02 09:03:10 -04:00
-DLIBUNWIND_TEST_CONFIG="ibm-libunwind-shared.cfg.in"
[libcxx][AIX] Enable ABI list checking for XCOFF The existing nm extractors can't dump the loader symbol table information we need to do the ABI checks for XCOFF, so provide an implementation using the system dump utility. We match the symbol name, whether it's defined, it's import/export status, and its storage mapping class. Reviewed By: #libc, ldionne Differential Revision: https://reviews.llvm.org/D124165
2022-06-14 13:15:46 -04:00
check-abi-list
[libunwind][ci][AIX] Add libunwind to buildbot CI Summary: This patch changes scripts to add libunwind CI on AIX. Test config file ibm-libunwind-shared.cfg.in is introduced for testing on AIX. Reviewed by: ldionne, MaskRay, libunwind, ibc++abi Differential Revision: https://reviews.llvm.org/D126017
2022-06-02 09:03:10 -04:00
check-runtimes
[libc++][AIX] Add scripts and config for building with the libcxx CI infrastructure This initial change adds the AIX configuration to run-buildbot, an AIX CMake cache file, and appropriate compiler and linker flags for testing AIX to the lit "from scratch" configuration files. Either of the 32-bit or 64-bit configurations can be built by setting `OBJECT_MODE` in the build environment (as is typical for AIX). Reviewed By: ldionne, #libc, #libc_abi Differential Revision: https://reviews.llvm.org/D111244
2021-10-13 11:41:47 -04:00
;;
[libc++][Android] Support libc++ testing on Android (#69274) I could probably break this commit into more pieces. --- This patch adds libc++ support for Android L (Android 5.0+) and up, tested using the Android team's current compiler, a recent version of the AOSP sysroot, and the x86[-64] Android Emulator. CMake and Lit Configuration: Add runtimes/cmake/android/Arch-${ARCH}.cmake files that configure CMake to cross-compile to Android without using CMake's built-in NDK support (which only works with an actual packaged NDK). Add libcxx/cmake/caches/AndroidNDK.cmake that builds and tests libc++ (and libc++abi) for Android. This file configures libc++ to match what the NDK distributes, e.g.: - libc++_shared.so (includes libc++abi objects, there is no libc++abi.so). libunwind is linked statically but not exported. - libc++_static.a (does not include libc++abi) and libc++abi.a - `std::__ndk1` namespace - All the libraries are built with `__ANDROID_API__=21`, even when they are linked to something targeting a higher API level. (However, when the Android LLVM team builds these components, they do not use these CMake cache files. Instead they use Python scripts to configure the builds. See https://android.googlesource.com/toolchain/llvm_android/.) Add llvm-libc++[abi].android-ndk.cfg.in files that test the Android NDK's libc++_shared.so. These files can target old or new Android devices. The Android LLVM team uses these test files to test libc++ for both arm/arm64 and x86/x86_64 architectures. The Android testing mode works by setting %{executor} to adb_run.py, which uses `adb push` and `adb shell` to run tests remotely. adb_run.py always runs tests as the "shell" user even on an old emulator where "adb unroot" doesn't work. The script has workarounds for old Android devices. The script uses a Unix domain socket on the host (--job-limit-socket) to restrict concurrent adb invocations. Compiling the tests is a major part of libc++ testing run-time, so it's desirable to exploit all the host cores without overburdening the test devices, which can have far fewer cores. BuildKite CI: Add a builder to run-buildbot, `android-ndk-*`, that uses Android Clang and an Android sysroot to build libc++, then starts an Android emulator container to run tests. Run the emulator and an adb server in a separate Docker container (libcxx-ci-android-emulator), and create a separate Docker image for each emulator OS system image. Set ADB_SERVER_SOCKET to connect to the container's adb server. Running the only adb server inside the container makes cleanup more reliable between test runs, e.g. the adb client doesn't create a `~/.android` directory and the adb server can be restarted along with the emulator using docker stop/run. (N.B. The emulator insists on connecting to an adb server and will start one itself if it can't connect to one.) The suffix to the android-ndk-* job is a label that concisely specifies an Android SDK emulator image. e.g.: - "system-images;android-21;default;x86" ==> 21-def-x86 - "system-images;android-33;google_apis;x86_64" ==> 33-goog-x86_64 Fixes: https://github.com/llvm/llvm-project/issues/69270 Differential Revision: https://reviews.llvm.org/D139147
2023-10-19 13:58:30 -07:00
android-ndk-*)
clean
ANDROID_EMU_IMG="${BUILDER#android-ndk-}"
. "${MONOREPO_ROOT}/libcxx/utils/ci/vendor/android/emulator-functions.sh"
if ! validate_emu_img "${ANDROID_EMU_IMG}"; then
[libc++] Add output groups to run-buildbot (#111739) This improves the CI output by providing collapsable sections for sub-parts of our build. This was originally opened as #75233. Co-authored-by: eric <eric@efcs.ca>
2024-10-11 09:29:47 -04:00
error "android-ndk suffix must be a valid emulator image (${ANDROID_EMU_IMG})" >&2
[libc++][Android] Support libc++ testing on Android (#69274) I could probably break this commit into more pieces. --- This patch adds libc++ support for Android L (Android 5.0+) and up, tested using the Android team's current compiler, a recent version of the AOSP sysroot, and the x86[-64] Android Emulator. CMake and Lit Configuration: Add runtimes/cmake/android/Arch-${ARCH}.cmake files that configure CMake to cross-compile to Android without using CMake's built-in NDK support (which only works with an actual packaged NDK). Add libcxx/cmake/caches/AndroidNDK.cmake that builds and tests libc++ (and libc++abi) for Android. This file configures libc++ to match what the NDK distributes, e.g.: - libc++_shared.so (includes libc++abi objects, there is no libc++abi.so). libunwind is linked statically but not exported. - libc++_static.a (does not include libc++abi) and libc++abi.a - `std::__ndk1` namespace - All the libraries are built with `__ANDROID_API__=21`, even when they are linked to something targeting a higher API level. (However, when the Android LLVM team builds these components, they do not use these CMake cache files. Instead they use Python scripts to configure the builds. See https://android.googlesource.com/toolchain/llvm_android/.) Add llvm-libc++[abi].android-ndk.cfg.in files that test the Android NDK's libc++_shared.so. These files can target old or new Android devices. The Android LLVM team uses these test files to test libc++ for both arm/arm64 and x86/x86_64 architectures. The Android testing mode works by setting %{executor} to adb_run.py, which uses `adb push` and `adb shell` to run tests remotely. adb_run.py always runs tests as the "shell" user even on an old emulator where "adb unroot" doesn't work. The script has workarounds for old Android devices. The script uses a Unix domain socket on the host (--job-limit-socket) to restrict concurrent adb invocations. Compiling the tests is a major part of libc++ testing run-time, so it's desirable to exploit all the host cores without overburdening the test devices, which can have far fewer cores. BuildKite CI: Add a builder to run-buildbot, `android-ndk-*`, that uses Android Clang and an Android sysroot to build libc++, then starts an Android emulator container to run tests. Run the emulator and an adb server in a separate Docker container (libcxx-ci-android-emulator), and create a separate Docker image for each emulator OS system image. Set ADB_SERVER_SOCKET to connect to the container's adb server. Running the only adb server inside the container makes cleanup more reliable between test runs, e.g. the adb client doesn't create a `~/.android` directory and the adb server can be restarted along with the emulator using docker stop/run. (N.B. The emulator insists on connecting to an adb server and will start one itself if it can't connect to one.) The suffix to the android-ndk-* job is a label that concisely specifies an Android SDK emulator image. e.g.: - "system-images;android-21;default;x86" ==> 21-def-x86 - "system-images;android-33;google_apis;x86_64" ==> 33-goog-x86_64 Fixes: https://github.com/llvm/llvm-project/issues/69270 Differential Revision: https://reviews.llvm.org/D139147
2023-10-19 13:58:30 -07:00
exit 1
fi
ARCH=$(arch_of_emu_img ${ANDROID_EMU_IMG})
# Use the Android compiler by default.
export CC=${CC:-/opt/android/clang/clang-current/bin/clang}
export CXX=${CXX:-/opt/android/clang/clang-current/bin/clang++}
# The NDK libc++_shared.so is always built against the oldest supported API
# level. When tests are run against a device with a newer API level, test
# programs can be built for any supported API level, but building for the
# newest API (i.e. the system image's API) is probably the most interesting.
[libc++] Remove LIBCXX_EXECUTOR and LIBCXXABI_EXECUTOR (#79886) Those were deprecated in LLVM 18 and their removal was planned for LLVM 19.
2024-02-26 14:46:15 -05:00
PARAMS="executor=${MONOREPO_ROOT}/libcxx/utils/adb_run.py;target_triple=$(triple_of_arch ${ARCH})$(api_of_emu_img ${ANDROID_EMU_IMG})"
[libc++][Android] Support libc++ testing on Android (#69274) I could probably break this commit into more pieces. --- This patch adds libc++ support for Android L (Android 5.0+) and up, tested using the Android team's current compiler, a recent version of the AOSP sysroot, and the x86[-64] Android Emulator. CMake and Lit Configuration: Add runtimes/cmake/android/Arch-${ARCH}.cmake files that configure CMake to cross-compile to Android without using CMake's built-in NDK support (which only works with an actual packaged NDK). Add libcxx/cmake/caches/AndroidNDK.cmake that builds and tests libc++ (and libc++abi) for Android. This file configures libc++ to match what the NDK distributes, e.g.: - libc++_shared.so (includes libc++abi objects, there is no libc++abi.so). libunwind is linked statically but not exported. - libc++_static.a (does not include libc++abi) and libc++abi.a - `std::__ndk1` namespace - All the libraries are built with `__ANDROID_API__=21`, even when they are linked to something targeting a higher API level. (However, when the Android LLVM team builds these components, they do not use these CMake cache files. Instead they use Python scripts to configure the builds. See https://android.googlesource.com/toolchain/llvm_android/.) Add llvm-libc++[abi].android-ndk.cfg.in files that test the Android NDK's libc++_shared.so. These files can target old or new Android devices. The Android LLVM team uses these test files to test libc++ for both arm/arm64 and x86/x86_64 architectures. The Android testing mode works by setting %{executor} to adb_run.py, which uses `adb push` and `adb shell` to run tests remotely. adb_run.py always runs tests as the "shell" user even on an old emulator where "adb unroot" doesn't work. The script has workarounds for old Android devices. The script uses a Unix domain socket on the host (--job-limit-socket) to restrict concurrent adb invocations. Compiling the tests is a major part of libc++ testing run-time, so it's desirable to exploit all the host cores without overburdening the test devices, which can have far fewer cores. BuildKite CI: Add a builder to run-buildbot, `android-ndk-*`, that uses Android Clang and an Android sysroot to build libc++, then starts an Android emulator container to run tests. Run the emulator and an adb server in a separate Docker container (libcxx-ci-android-emulator), and create a separate Docker image for each emulator OS system image. Set ADB_SERVER_SOCKET to connect to the container's adb server. Running the only adb server inside the container makes cleanup more reliable between test runs, e.g. the adb client doesn't create a `~/.android` directory and the adb server can be restarted along with the emulator using docker stop/run. (N.B. The emulator insists on connecting to an adb server and will start one itself if it can't connect to one.) The suffix to the android-ndk-* job is a label that concisely specifies an Android SDK emulator image. e.g.: - "system-images;android-21;default;x86" ==> 21-def-x86 - "system-images;android-33;google_apis;x86_64" ==> 33-goog-x86_64 Fixes: https://github.com/llvm/llvm-project/issues/69270 Differential Revision: https://reviews.llvm.org/D139147
2023-10-19 13:58:30 -07:00
generate-cmake-android -C "${MONOREPO_ROOT}/runtimes/cmake/android/Arch-${ARCH}.cmake" \
-C "${MONOREPO_ROOT}/libcxx/cmake/caches/AndroidNDK.cmake" \
-DCMAKE_SYSROOT=/opt/android/ndk/sysroot \
-DLIBCXX_TEST_PARAMS="${PARAMS}" \
-DLIBCXXABI_TEST_PARAMS="${PARAMS}"
[libc++][Android] Add NDK ABI lists for i686 and x86_64 (#69272) This commit adds ABI lists for the Android NDK. Fixes: https://github.com/llvm/llvm-project/issues/69270 Differential Revision: https://reviews.llvm.org/D155341
2024-01-12 13:00:16 -08:00
check-abi-list
[libc++][Android] Support libc++ testing on Android (#69274) I could probably break this commit into more pieces. --- This patch adds libc++ support for Android L (Android 5.0+) and up, tested using the Android team's current compiler, a recent version of the AOSP sysroot, and the x86[-64] Android Emulator. CMake and Lit Configuration: Add runtimes/cmake/android/Arch-${ARCH}.cmake files that configure CMake to cross-compile to Android without using CMake's built-in NDK support (which only works with an actual packaged NDK). Add libcxx/cmake/caches/AndroidNDK.cmake that builds and tests libc++ (and libc++abi) for Android. This file configures libc++ to match what the NDK distributes, e.g.: - libc++_shared.so (includes libc++abi objects, there is no libc++abi.so). libunwind is linked statically but not exported. - libc++_static.a (does not include libc++abi) and libc++abi.a - `std::__ndk1` namespace - All the libraries are built with `__ANDROID_API__=21`, even when they are linked to something targeting a higher API level. (However, when the Android LLVM team builds these components, they do not use these CMake cache files. Instead they use Python scripts to configure the builds. See https://android.googlesource.com/toolchain/llvm_android/.) Add llvm-libc++[abi].android-ndk.cfg.in files that test the Android NDK's libc++_shared.so. These files can target old or new Android devices. The Android LLVM team uses these test files to test libc++ for both arm/arm64 and x86/x86_64 architectures. The Android testing mode works by setting %{executor} to adb_run.py, which uses `adb push` and `adb shell` to run tests remotely. adb_run.py always runs tests as the "shell" user even on an old emulator where "adb unroot" doesn't work. The script has workarounds for old Android devices. The script uses a Unix domain socket on the host (--job-limit-socket) to restrict concurrent adb invocations. Compiling the tests is a major part of libc++ testing run-time, so it's desirable to exploit all the host cores without overburdening the test devices, which can have far fewer cores. BuildKite CI: Add a builder to run-buildbot, `android-ndk-*`, that uses Android Clang and an Android sysroot to build libc++, then starts an Android emulator container to run tests. Run the emulator and an adb server in a separate Docker container (libcxx-ci-android-emulator), and create a separate Docker image for each emulator OS system image. Set ADB_SERVER_SOCKET to connect to the container's adb server. Running the only adb server inside the container makes cleanup more reliable between test runs, e.g. the adb client doesn't create a `~/.android` directory and the adb server can be restarted along with the emulator using docker stop/run. (N.B. The emulator insists on connecting to an adb server and will start one itself if it can't connect to one.) The suffix to the android-ndk-* job is a label that concisely specifies an Android SDK emulator image. e.g.: - "system-images;android-21;default;x86" ==> 21-def-x86 - "system-images;android-33;google_apis;x86_64" ==> 33-goog-x86_64 Fixes: https://github.com/llvm/llvm-project/issues/69270 Differential Revision: https://reviews.llvm.org/D139147
2023-10-19 13:58:30 -07:00
${NINJA} -vC "${BUILD_DIR}" install-cxx install-cxxabi
# Start the emulator and make sure we can connect to the adb server running
# inside of it.
"${MONOREPO_ROOT}/libcxx/utils/ci/vendor/android/start-emulator.sh" ${ANDROID_EMU_IMG}
trap "${MONOREPO_ROOT}/libcxx/utils/ci/vendor/android/stop-emulator.sh" EXIT
. "${MONOREPO_ROOT}/libcxx/utils/ci/vendor/android/setup-env-for-emulator.sh"
# Create adb_run early to avoid concurrent `mkdir -p` of common parent
# directories.
adb shell mkdir -p /data/local/tmp/adb_run
adb push "${BUILD_DIR}/lib/libc++_shared.so" /data/local/tmp/libc++/libc++_shared.so
[libc++] Add output groups to run-buildbot (#111739) This improves the CI output by providing collapsable sections for sub-parts of our build. This was originally opened as #75233. Co-authored-by: eric <eric@efcs.ca>
2024-10-11 09:29:47 -04:00
step "Running the libc++ tests"
[libc++][Android] Support libc++ testing on Android (#69274) I could probably break this commit into more pieces. --- This patch adds libc++ support for Android L (Android 5.0+) and up, tested using the Android team's current compiler, a recent version of the AOSP sysroot, and the x86[-64] Android Emulator. CMake and Lit Configuration: Add runtimes/cmake/android/Arch-${ARCH}.cmake files that configure CMake to cross-compile to Android without using CMake's built-in NDK support (which only works with an actual packaged NDK). Add libcxx/cmake/caches/AndroidNDK.cmake that builds and tests libc++ (and libc++abi) for Android. This file configures libc++ to match what the NDK distributes, e.g.: - libc++_shared.so (includes libc++abi objects, there is no libc++abi.so). libunwind is linked statically but not exported. - libc++_static.a (does not include libc++abi) and libc++abi.a - `std::__ndk1` namespace - All the libraries are built with `__ANDROID_API__=21`, even when they are linked to something targeting a higher API level. (However, when the Android LLVM team builds these components, they do not use these CMake cache files. Instead they use Python scripts to configure the builds. See https://android.googlesource.com/toolchain/llvm_android/.) Add llvm-libc++[abi].android-ndk.cfg.in files that test the Android NDK's libc++_shared.so. These files can target old or new Android devices. The Android LLVM team uses these test files to test libc++ for both arm/arm64 and x86/x86_64 architectures. The Android testing mode works by setting %{executor} to adb_run.py, which uses `adb push` and `adb shell` to run tests remotely. adb_run.py always runs tests as the "shell" user even on an old emulator where "adb unroot" doesn't work. The script has workarounds for old Android devices. The script uses a Unix domain socket on the host (--job-limit-socket) to restrict concurrent adb invocations. Compiling the tests is a major part of libc++ testing run-time, so it's desirable to exploit all the host cores without overburdening the test devices, which can have far fewer cores. BuildKite CI: Add a builder to run-buildbot, `android-ndk-*`, that uses Android Clang and an Android sysroot to build libc++, then starts an Android emulator container to run tests. Run the emulator and an adb server in a separate Docker container (libcxx-ci-android-emulator), and create a separate Docker image for each emulator OS system image. Set ADB_SERVER_SOCKET to connect to the container's adb server. Running the only adb server inside the container makes cleanup more reliable between test runs, e.g. the adb client doesn't create a `~/.android` directory and the adb server can be restarted along with the emulator using docker stop/run. (N.B. The emulator insists on connecting to an adb server and will start one itself if it can't connect to one.) The suffix to the android-ndk-* job is a label that concisely specifies an Android SDK emulator image. e.g.: - "system-images;android-21;default;x86" ==> 21-def-x86 - "system-images;android-33;google_apis;x86_64" ==> 33-goog-x86_64 Fixes: https://github.com/llvm/llvm-project/issues/69270 Differential Revision: https://reviews.llvm.org/D139147
2023-10-19 13:58:30 -07:00
${NINJA} -vC "${BUILD_DIR}" check-cxx
[libc++] Add output groups to run-buildbot (#111739) This improves the CI output by providing collapsable sections for sub-parts of our build. This was originally opened as #75233. Co-authored-by: eric <eric@efcs.ca>
2024-10-11 09:29:47 -04:00
step "Running the libc++abi tests"
[libc++][Android] Support libc++ testing on Android (#69274) I could probably break this commit into more pieces. --- This patch adds libc++ support for Android L (Android 5.0+) and up, tested using the Android team's current compiler, a recent version of the AOSP sysroot, and the x86[-64] Android Emulator. CMake and Lit Configuration: Add runtimes/cmake/android/Arch-${ARCH}.cmake files that configure CMake to cross-compile to Android without using CMake's built-in NDK support (which only works with an actual packaged NDK). Add libcxx/cmake/caches/AndroidNDK.cmake that builds and tests libc++ (and libc++abi) for Android. This file configures libc++ to match what the NDK distributes, e.g.: - libc++_shared.so (includes libc++abi objects, there is no libc++abi.so). libunwind is linked statically but not exported. - libc++_static.a (does not include libc++abi) and libc++abi.a - `std::__ndk1` namespace - All the libraries are built with `__ANDROID_API__=21`, even when they are linked to something targeting a higher API level. (However, when the Android LLVM team builds these components, they do not use these CMake cache files. Instead they use Python scripts to configure the builds. See https://android.googlesource.com/toolchain/llvm_android/.) Add llvm-libc++[abi].android-ndk.cfg.in files that test the Android NDK's libc++_shared.so. These files can target old or new Android devices. The Android LLVM team uses these test files to test libc++ for both arm/arm64 and x86/x86_64 architectures. The Android testing mode works by setting %{executor} to adb_run.py, which uses `adb push` and `adb shell` to run tests remotely. adb_run.py always runs tests as the "shell" user even on an old emulator where "adb unroot" doesn't work. The script has workarounds for old Android devices. The script uses a Unix domain socket on the host (--job-limit-socket) to restrict concurrent adb invocations. Compiling the tests is a major part of libc++ testing run-time, so it's desirable to exploit all the host cores without overburdening the test devices, which can have far fewer cores. BuildKite CI: Add a builder to run-buildbot, `android-ndk-*`, that uses Android Clang and an Android sysroot to build libc++, then starts an Android emulator container to run tests. Run the emulator and an adb server in a separate Docker container (libcxx-ci-android-emulator), and create a separate Docker image for each emulator OS system image. Set ADB_SERVER_SOCKET to connect to the container's adb server. Running the only adb server inside the container makes cleanup more reliable between test runs, e.g. the adb client doesn't create a `~/.android` directory and the adb server can be restarted along with the emulator using docker stop/run. (N.B. The emulator insists on connecting to an adb server and will start one itself if it can't connect to one.) The suffix to the android-ndk-* job is a label that concisely specifies an Android SDK emulator image. e.g.: - "system-images;android-21;default;x86" ==> 21-def-x86 - "system-images;android-33;google_apis;x86_64" ==> 33-goog-x86_64 Fixes: https://github.com/llvm/llvm-project/issues/69270 Differential Revision: https://reviews.llvm.org/D139147
2023-10-19 13:58:30 -07:00
${NINJA} -vC "${BUILD_DIR}" check-cxxabi
;;
[libc++] NFC: Make it easier for vendors to extend the run-buildbot script
2021-05-27 16:51:38 -04:00
#################################################################
# Insert vendor-specific internal configurations below.
#
# This allows vendors to extend this file with their own internal
# configurations without running into merge conflicts with upstream.
#################################################################
#################################################################
[libc++] Initial support for pre-commit CI with Buildkite This commit adds basic files and scripts that are used for the Buildkite pre-commit CI setup. This was tested to mostly work on a fork of llvm-project, however some adjustments will have to be made as we complete the real setup.
2020-09-23 09:20:03 -04:00
*)
echo "${BUILDER} is not a known configuration"
exit 1
;;
esac
[libc++] Add output groups to run-buildbot (#111739) This improves the CI output by providing collapsable sections for sub-parts of our build. This was originally opened as #75233. Co-authored-by: eric <eric@efcs.ca>
2024-10-11 09:29:47 -04:00
endstep # Make sure we close any still-open output group
Reference in New Issue Copy Permalink