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.
swift-reflection-dump, a host-side tool, requires this library that
normally builds for the configured platform. So, if the host platform
isn't configured to build for some reason, swift-reflection-dump will
fail to link.
swift-reflection-test is now the test that forks a swift executable
and performs remote reflection, making it runnable on other targets,
such as the iOS simulator.
swift-reflection-dump is now a host-side tool that dumps the remote
reflection sections for any platform binary and will continue to
link in LLVM object file support.
This necessitates finally moving lib/Refleciton into stdlib/public,
since we're linking target-specific versions of the test tool and
we would eventually like to adopt some of this functionality in
the runtime anyway.
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.
Using Clang to compile API notes introduces a dependency on the
underlying Clang, which can cause problems as Clang's support for API
notes evolves. Re-introduce the "-apinotes" driver flag into the Swift
driver to allow us to compile API notes, and use that (rather than
Clang) to precompile API notes for the overlays.
I am going to use the link job for limiting swift lto compile time.
The reason not to use the same variables as LLVM (i.e. LLVM_PARALLEL_LINK_JOBS)
is that Swift since it is compiling more IR may have a larger memory
representation implying less parallel linking jobs than LLVM can be used on
bots.
When I originally committed the LTO code, I tried to match the coding style of
the code right above it that enabled code coverage. Turns out that the code
coverage code did not have a weird coding style and instead just had a bug.
I fixed both of the issues and also enabled the LTO flag on non-Darwin.
Pre-specializations were only used by Onone builds, but were kept inside the standard library dylyb anyways. This commit moves all the pre-specializations into a dedicated Swift module and a dynamic library, which are only used by Onone builds.
This reduces the code size of libswiftCore.dylib by 4%-5%.
This doesn't hit the runtime. I am going to try that in a little bit.
I saw some nice reductions in compile time in the SILOptimizer in the stdlib.
Specifically, we went from spending ~33 seconds in the siloptimizer -> ~23
seconds. There were other improvements as well.
Keep in mind, I have not tested this with debug info, so it may hog all of your
ram due to crazy amounts of debug info. It would be good to try and do what LLVM
does which is to compile with line tables but not full types.
rdar://24717107
Update the paths that we look in for the cmake modules from LLVM which changed
recently on SVN trunk. Check the old paths first, and if that fails, check the
new path. This permits building against either layout.
The Xlinker flags were getting globbed into a single string since
we started adding current/compatibility version arguments to the
linker.
rdar://problem/24622276
The short-term goal here is to get everything compiling and all the tests
passing.
The mid-term goal is to test the performance of a resilient stdlib.
The long-term goal is to make this the default (and only) build mode.
This should be considered EXPERIMENTAL; we can't even build libSwiftCore
successfully yet.
This brings down StdlibUnittest build time to 90 seconds with either
a DebugAssert or a ReleaseAssert compiler.
The new library, StdlibCollectionTests, is only built when running
validation tests.
We don't want references to local symbols within an image to be relocatable, since this increases startup time and causes problems with relative references.
Although the user sets the option using `--sil-verify-all`, various
build scripts refer to the option as `SWIFT_VERIFY_ALL`. Code comments
indicate that this may have been a separate setting at one time.
Remove the misleading comments and unify naming with
`--sil-verify-all` and `SWIFT_SIL_VERIFY_ALL`. This more closely matches what
the option actually does (adds `-Xfrontend -sil-verify-all` to `swiftc`
invocations during the build process).
