The Swift driver does not update the mtime of the output files if the
existing output files on disk are identical to the ones that are about
to be written. This behavior confuses the makefiles used in CMake Xcode
projects: the makefiles will not consider everything up to date after
invoking the compiler. As a result, the standard library gets rebuilt
multiple times during a single build.
To work around this issue we touch the output files so that their mtime
always gets updated.
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
GNU ld seems to have problems with PC-relative references to
protected functions that aren't calls. We'll generate that
pattern in Swift code in release builds because of function
merging. The workaround is to just not tell the compiler
that these symbols can be addressed PC-relative when we might
be using GNU ld, which I've conservatively approximated as
"not Darwin" while I try to figure out what changed to cause this.
Declarations with protected visibility are assumed to be defined
within the current linkage unit, so we have to use default visibility
if we don't know that we're building that. Teach the shim
visibility header to only use protected visibility when the
__SWIFT_CURRENT_DYLIB macro is defined, and define it when building
the standard library. Eventually we should change
SWIFT_RUNTIME_STDLIB_INTERFACE and SWIFT_RUNTIME_EXPORT to be
parameterized by the defining dylib so that this works for all the
overlay stubs, too; for now, special-casing swiftCore is necessary
to fix the LInux build.
A script checks if the output object file is written only once even if the compiler is invoked multiple times.
The main purpose of this check is to ensure that the compiler is deterministic (until IRGen).
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`.
Otherwise, we may get lipo from the wrong toolchain and it may not be
able to understand all of the architectures/bit code we are lipoing
together yielding an unknown architecture error.
rdar://24717107
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.
