Strictly separate "argument tweak" and "build-script-lmpl args generation"
* tweak `args` - set default, propagate default
* (Do something in `build-script`)
* build `build_script_impl_args`
- Get it to work as `build-script` arguments.
- Fixed quoting problem
- Replaced --user-config-args: Error for --user-config-args.
- Moved to the position where it can override any options
Before, we have to explicitly specify migrated args:
migrate_impl_args(argv, [... migrated arg list ...])
This change makes all *unknown* arguments to be automatically forwarded to
'build-script-impl'.
- Update the documentation to reflect that Swift supports (only)
the latest NDK version. Based on what I've heard from Android
developers that use the NDK, this is a reasonable requirement.
- The most recent version of the Android NDK no longer includes a
"4.8" toolchain version. Change the default to "4.9", and update
the paths in the documentation to match.
- The build script option "--android-ndk-version" was misleading.
This parameter actually refers to the Android API level. Swift
currently supports 21 (Android 5.0) and above (although supporting
lower API levels would be desirable).
This fixes a regression from PR #2213.
We needed a way to disable testing in a preset, even though previous
flags already requested tests. So I added an argument to the '--test'
and '--validation-test' flags. The argparse module treats '-T' and
'--validation-test' the same, so it thinks that in -RTi the 'i' is an
argument to '-T'.
* The behavior of `build-script -t` is unchanged.
* `build-script -T` continues to run primary and validation test suite,
but without the long tests.
* `build-script --long-test` runs just the long tests.
* `build-script -T --long-test` runs all tests.
I've only implemented this for OS X, which comes with the
'caffeinate' command. If anyone would like to implement
something similar for Linux, feel free. (Although please
make sure that it's signal-safe, i.e. if the build is
interrupted the computer's sleep settings return to normal.)
Migrate the logic that determines which platforms to build the stdlib
for to Python. This is applies both as an effort to migrate more of the
build script to Python (https://bugs.swift.org/browse/SR-237), but also
as a means of splitting up the work necessary to cross-compile the Swift
stdlib from OS X to Linux.
This adds an Android target for the stdlib. It is also the first
example of cross-compiling outside of Darwin.
Mailing list discussions:
1. https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20151207/000171.html
2. https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20151214/000492.html
The Android variant of Swift may be built using the following `build-script`
invocation:
```
$ utils/build-script \
-R \ # Build in ReleaseAssert mode.
--android \ # Build for Android.
--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/
```
Android builds have the following dependencies, as can be seen in
the build script invocation:
1. An Android NDK of version 21 or greater, available to download
here: http://developer.android.com/ndk/downloads/index.html.
2. A libicu compatible with android-armv7.
Not all machines may have all platforms' SDKs installed.
xcodebuild already has a command to print the versions of all
SDKs installed. For convenience, also provide a function that
returns the identifiers for all installed SDKs.
rdar://problem/25618455
