_OBJECT_FORMAT was added recentlyish for all the SDKs. Use that property rather
than enumerating all the ELFish targets. This ensures that the code path is
correct if another ELFish target is ported to.
Add an option which the user can specify to switch to the lld linker. Although
this linker is still nascent, it is interesting to permit linking with this. It
is also an alternative to the BFD linker for COFF targets. It will allow for a
cross-compilation story for Windows on non-Windows targets.
This allows us to cross-compile the standard library to foreign targets on a
single host. The ICU dependencies can be specified on the command line on a
per-target basis. If one is not specified, we fall back to the default search
path and use that for the other targets.
Special thanks to Dimitri Gribenko for the various hints in getting this wired
up.
This splits the `--build-swift-stdlib` and `--build-swift-sdk-overlay`
arguments into `dynamic` and `static` variants, which makes the
following build command possible:
```
utils/build-script -- \
--build-swift-dynamic-stdlib=0 --build-swift-dynamic-sdk-overlay=0 \
--build-swift-static-stdlib=1 --build-swift-static-sdk-overlay=0
```
This command produces *only* static libraries for the stdlib, and no
SDK overlay libraries at all. Many other finely-grained build options
are now possible.
The Android NDK r12 release appends a ".x" to the libgcc directory;
it is now:
```
android-ndk-r12/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/lib/gcc/arm-linux-androideabi/4.9.x
```
Update the linker path for the Android build to accomodate this change.
gold only supports ELF. This adds two new helper functions
(is_windows_based_sdk and is_elfish_sdk) to ensure that we dont try to use gold
on non-ELF targets. This comes up when trying to setup cross-compilation for
the standard library for Windows.
The ELF check is implemented as the negation of Darwin (which uses MachO) and
Windows (which uses COFF). The reason for this is that there are additional
targets which also use ELF. Rather than enumerating the larger set, enumerate
the smaller set (windows) and use the negation.
Create a helper function to determine if we are targeting a Darwin SDK or not.
The repetition is error-prone and verbose. Simplify by adding a checking
function. NFC.
Use the SWIFTLIB_SINGLE_SDK variable rather than the CMAKE_BUILD_SYSTEM variable
to determine the target type. This allows us to use the logic for adding
libraries for foreign OSes on a build host. This is needed to pave the road to
cross-crompiling the standard library for different targets.
The use of `-isysroot` is a Darwin specific behaviour. It is used to switch to
a platform SDK, however, other targets use the `--sysroot` flag. Windows uses a
custom mechanism which is a set of system header paths.
As a first step to allowing the build script to build *only*
static library versions of the stdlib, change `add_swift_library`
such that callers must pass in `SHARED`, `STATIC`, or `OBJECT_LIBRARY`.
Ideally, only these flags would be used to determine whether to
build shared, static, or object libraries, but that is not currently
the case -- `add_swift_library` also checks whether the library
`IS_STDLIB` before performing certain additional actions. This will be
cleaned up in a future commit.
HOST_LIBRARY is supposed to mean "no matter what the defaults say, also build
this library for the host". FORCE_BUILD_FOR_HOST_SDK is a less confusing name.
At some point in the future, we may consider using LTO on the runtime/standard
library, but right now is not that time. We are just trying to use LTO to
improve the compile time performance of the compiler itself.
rdar://24717107
This will allow control on the outside of these calls on whether or not LTO is
enabled. This is necessary for turning off LTO on target libraries.
rdar://24717107
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.
