- 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).
* 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.
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.
build-script-impl now takes a --lldb-test-cc flag:
* when not specified, it will default to using the
just-built clang (i.e. in tree with swift) to
build the C/C++ test suite test inferior programs.
* when specified and equal to "host-toolchain", the
test suite test inferiors will be built with
the same compiler chosen as --host-cc.
* when set to anything else, it is assumed to be the
full path to a C compiler to use for compiling
LLDB test suite test inferiors.
Note the LLDB test suite only takes the C compiler and
derives the C++ compiler from the C compiler path. There
is no need to specify the C++ compiler directly.
Addresses the following issue:
https://bugs.swift.org/browse/SR-1207
Fix the OS X XCTest CI preset:
1. Installation of XCTest isn't supported on OS X. After all, the
library is meant to be used on Linux, and not intended to be used or
installed on OS X. Therefore, no longer pass an `INSTALL_PATH` to the
`xcodebuild` invocation on OS X.
2. `xcodebuild` expects `swift-stdlib-tool` to be present in the same
directory as the `SWIFT_EXEC` it's given. Re-use some shellscript
from the toolchain installation script to copy the stdlib-tool
substitute.
This allows the XCTest CI to work on all platforms.
When enabling ASAN on LLVM it does not build the asan libraries, and this means
that we can't use it to sanitize swift. This change disables ASAN on the
internal clang but keeps it on the Swift project.
This commit makes the swift build scripts use the clang that we build as part of
the build process in order to build the Swift runtime, and not the host
compiler. This change is necessary for using new clang features immediately after they are introduced.
One example for such feature is new function calling conventions, or new c-level attributes.
We want to have the option of building the standard library without
-sil-serialize-all.
For now, the build crashes in the SIL verifier due to various issues;
upcoming patches will address these.
This is part of the larger goal of building the stdlib with
-enable-resilience.
Part of https://bugs.swift.org/browse/SR-267.
The XCTest CI is currently broken for OS X. Invoking `xcodebuild`, even
when setting the correct `SWIFT_EXEC`, was unable to build Foundation.
The problem was that a flag to link the Objective-C runtime was not being set
as it would be when building with a Swift toolchain.
Set the flag to get the builds passing. The XCTest CI presets should
pass on all platforms with this change.
Because the `xcodebuild` invocation used to compile swift-corelibs-xctest on OS X uses a toolchain that is usually out of date, it often fails (for example, when building the newly migrated Swift 3 code).
Pass the path to the freshly built `swiftc` to `xcodebuild` in order to use the latest Swift compiler.
