Rather than having the cmake generator be decided by 3 different options that
can be potentially all set (which makes no sense), this should really just be an
option called cmake_generator that would default to ninja and would have choices
of xcode, eclipse, etc.
Communicate build variant selection to libdispatch build process
using the --with-build-variant argument to libdispatch's configure
script added in libdispatch pull request #110.
This enables you to know what tests actually ran instead of just the number of
tests that ran. This helps identify:
1. Tests that are not running, but /should/ be running.
2. Tests that are XFAILED or DISABLED but should not be.
This splits the `--build-swift-stdlib` and `--build-swift-sdk-overlay`
arguments into `dynamic` and `static` variants, which makes the
following build command possible:
```
utils/build-script -- \
--build-swift-dynamic-stdlib=0 --build-swift-dynamic-sdk-overlay=0 \
--build-swift-static-stdlib=1 --build-swift-static-sdk-overlay=0
```
This command produces *only* static libraries for the stdlib, and no
SDK overlay libraries at all. Many other finely-grained build options
are now possible.
When the "--android-deploy-device-path" option was first added,
build products would only be deployed to a connected Android device
if the option was specified. Now, we use `command_upload_stdlib`
to upload every time the Android tests are being run.
As a result, running the test suite for Android without specifying
a deploy path leads to a subtle error, in which the
`command_upload_stdlib` CMake command fails. End users may find this
difficult to debug.
Add a default argument to the deployment path, and check for a valid
path before executing the CMake command.
- This fixes a regression introduced in
a4537e8a0f, where we used to accept a list of
concatenated deployment targets as a single argument.
- <rdar://problem/26928189> build-script fails to split deployment targets
before iterating over them
- This change moves the top-level invocation driver loop into `build-script`
and uses the `-impl` script to perform each individual action. Once landed
and enabled, this will enable us to migrate the individual pieces of the
`-impl` script into Python code in an incremental fashion.
- This also introduces stub product definitions for each of the different projects
we manage.
- This works, but is disabled by default (`--no-legacy-impl`) because it
severely impacts the performance of null builds (4x slower, currently) due to
the `build-script-impl` parsing overhead. If only we had a JITing bash
implementation...
At some point in the future, we may consider using LTO on the runtime/standard
library, but right now is not that time. We are just trying to use LTO to
improve the compile time performance of the compiler itself.
rdar://24717107
This adds support for running tests for the stdlib built
for Android, both on the host machine and on an Android device.
The Android variant of Swift may be built and tested using
the following `build-script` invocation:
```
$ utils/build-script \
-R \ # Build in ReleaseAssert mode.
-T \ # Run all tests.
--android \ # Build for Android.
--android-deploy-device-path /data/local/tmp \ # Temporary directory on the device where Android tests are run.
--android-ndk ~/android-ndk-r10e \ # Path to an Android NDK.
--android-ndk-version 21 \
--android-icu-uc ~/libicu-android/armeabi-v7a/libicuuc.so \
--android-icu-uc-include ~/libicu-android/armeabi-v7a/icu/source/common \
--android-icu-i18n ~/libicu-android/armeabi-v7a/libicui18n.so \
--android-icu-i18n-include ~/libicu-android/armeabi-v7a/icu/source/i18n/
```
See docs/Testing.rst for more details.
https://github.com/apple/swift/pull/2880 appends a `Target` instance
to an array of strings when building Android. This causes a syntax
error when building Android. Fix the error to repair the Android
build.
- Introduces a new `HostSpecificConfiguration` which holds the computed
information for each host we need to use.
- This relies on the functionality to pass host-specific variables to the
script via environment variables.
- The computation itself has been cleaned up a tiny bit (mostly via using
the factored out platform/target properties), but is otherwise a straight
port of the logic from `build-script-impl`.
- This commit does not yet remove that code from `build-script-impl`; instead
it validates that the two implementations are computing the same result.
This is useful right now for testing the validity of the port.
- This isn't yet used, but we need an easy way for `build-script` to
pass host-specific variables down to `build-script-impl`.
- I don't think it is worth complicating the main argument parsing
logic with a syntax for passing associative arrays on the command
line, so this just passes them via environment variables.
- Part of SR-237.
- This is an object designed to represent a single invocation of the build
script, primarily for use in decomposing the main program flow into its
distinct conceptual pieces.
- This adds a new argument `--only-execute <name>` which can be used by
`build-script` to invoke the `build-script-impl` to perform each different
action, while moving the high-level operation loop into the `build-script`
itself. This should make incremental refactoring of the individual actions
into `build-script` easier.
- This is part of SR-237.
- This uses more Clang/Swift-style diagnostics, and adds a convenient wrapper
`fatal()` which happens to match what almost all clients of the previous
`print_with_argv0` wanted to do (i.e., fail with a fatal error).
- As part of this, I also tried to make the diagnostics more consistent and use
"diagnostic style" casing/punctuation.
- Part of SR-237.
