not IS_STDLIB. There are other non-stdlib libraries that can go
into the platform resource directory, such as libswiftRemoteMirror.dylib.
rdar://problem/26435454
Although this is a target library, it does not need to link against
the standard library, because it doesn't have any Swift content in
it. We need to add a separate build flag for having CMake content
because saying a library "IS_STDLIB" isn't correct for this case.
rdar://problem/26399625
Create a new CMake file responsible for functions that handle Swift
source files, such as `handle_swift_sources`. Also, add a new function,
`add_swift_source_group`, to this file. This function reduces some
duplication in `AddSwift.cmake`.
These types are not directly referenced as fields of aggregate types,
but are needed for reflection type lowering.
Also, use a SetVector to collect referenced builtin types, instead of
a SmallPtrSet, to ensure compiler output is deterministic.
swift-remote-ast has dependencies that cannot be satisfied by all
of the targets Swift supports. Specifically, the Android target is
unable to link libraries that libRemoteAST depends on, such as uuid.
To fix builds for unsupported platforms, only build remoteast-test
for the host platform.
- 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 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
The Xlinker flags were getting globbed into a single string since
we started adding current/compatibility version arguments to the
linker.
rdar://problem/24622276
