Add support for testing with macCatalyst to lit.cfg and the test CMake.
This adds lit test features for whether the standard library and runtime was
built with macCatalyst support:
REQUIRES: maccatalyst_support
The test suite can also be run in two modes: one where the macOS tests
are run as usual (against a zippered standard library, runtime, and overlays)
and another where iOS tests are compiled with the macCatalyst target
triple and executed as macCatalyst processes.
The iOS tests for macCatalyst can be run by passing `--maccatalyst-ios-tests`
to build-script. There are new lit test features to enable a test to specify
whether it supports that environment:
REQUIRES: OS=maccatalyst
UNSUPPORTED: OS=macCatalyst
This commit adds initial build system support for macCatalyst,
an Apple technology that enables code targeting iOS
to be recompiled so that it can be executed on macOS while still using
iOS APIs. This is the first in a series of commits building out support for
macCatalyst in the compiler, runtime, standard library, and overlays. Swift
for macCatalyst represents the work of multiple people, including
Devin Coughlin, Ross Bayer, and Brent Royal-Gordon.
Under macCatalyst, compiler-provided shared libraries (including overlays)
are built as one of four kinds (or "flavors") of libraries,
each with different install names and Mach-O load commands. This commit
adds the build system infrastructure to produce these different
library flavors.
**macOS-like Libraries**
A "macOS-like" library (such as the GLKit overlay) is a plain-old macOS library
that can only be loaded into regular macOS processes. It has a macOS slice with
a single load command allowing it to be loaded into normal macOS processes.
**iOS-like Libraries**
An "iOS-like" library, such as the UIKit overlay, is a library with a
macOS slice but with a load command that only allows it be loaded into
macCatalyst processes. iOS-like libraries are produced by passing a new
target tuple to the compiler:
swiftc ... -target x86_64-apple-ios13.0-macabi ...
Here 'ios' (and an iOS version number) is used for OS portion
of the triple, but the 'macabi' environment tells the compiler
that the library is intended for macCatalyst.
**Zippered Libraries**
A "zippered" library can be loaded into either a macCatalyst process or
a standard macOS process. Since macCatalyst does not introduce a new Mach-O
slice, the same code is shared between both processes. Zippered libraries
are usually relatively low level and with an API surface that is similar
between macOS and iOS (for example, both the Foundation overlay and the Swift
Standard Library/Runtime itself are zippered).
Zippered libraries are created by passing both the usual `-target`
flag to the compiler and an additional `-target-variant` flag:
swiftc ... -target x86_64-apple-macos10.15 \
-target-variant x86_64-apple-ios13.0-macabi
Just like the -target flag, -target-variant takes a target tuple.
This tells the compiler to compile the library for the -target tuple but
to add an extra load command, allowing the library to be loaded into processes
of the -target-variant flavor as well.
While a single zippered library and slice is shared between macOS and
macCatalyst, zippered libraries require two separate .swiftinterface/.swiftmodule
files, one for macOS and one for macCatalyst. When a macOS or macCatalyst client
imports the library, it will use module file for its flavor to determine what
symbols are present. This enables a zippered library to expose a subset of its
target APIs to its target-variant.
**Unzippered-Twin Libraries**
"Unzippered Twins" are pairs of libraries with the same name but different
contents and install locations, one for use from macOS processes and one for
use from macCatalyst processes. Unzippered twins are usually libraries that
depend on AppKit on macOS and UIKit on iOS (for example, the MapKit overlay)
and so do not share a common implementation between macOS and macCatalyst.
The macCatalyst version of an unzippered twin is installed in a parallel
directory hierarchy rooted at /System/iOSSupport/. So, for example, while macOS
and zippered Swift overlays are installed in /usr/lib/swift/, iOS-like and
the macCatalyst side of unzippered twins are installed in
/System/iOSSupport/usr/lib/swift. When building for macCatalyst, the build system
passes additional search paths so that the macCatalyst version of libraries is
found before macOS versions.
The add_swift_target_library() funciton now take an
optional MACCATALYST_BUILD_FLAVOR, which enables swift libraries to indicate
which flavor of library they are.
The Version object used __slots__ instead of __dict__, so it was not serializable. Update JSONDumper to stringify objects if vars() won’t work.
This change does not update any tests because build-script does not currently have a way to write full-script integration tests.
This makes the product computation more terse and adds the missing
options. The functional aspects of this change include renaming the
`SKIP_BUILD_SWIFT_STATIC_LIBDISPATCH` to `SKIP_BUILD_STATIC_LIBDISPATCH`
which keeps it in line with the other skip options. We also now list
the option properly.
Move the special flag handling for the non-atomic runtime into the build
system rather than spreading it across the build system and the helper
utilities.
This new module uses the build_swift.shell.ExecutableWrapper API to create a wrapper class around 'xcrun'. The wrapper class is instantiated and exposed under the name build_swift.wrappers.xcrun.
Having the test directory match the module we are testing means we can have scripts in the top level of utils/build_swift which can also have tests. As part of this re-structure the test utilties have been simplified somewhat and all tests no longer use a custom TestCase, rather the standard one exposed by the unittest module.
Teach build-script to print the list of valid targets for the
--stdlib-deployment-targets option. Unfortunately, passing all
supported targets to this option is the only way to force
configuration of those targets. Simply using --ios is no longer
sufficient--none of the iOS targets are actually configured unless you
ask them to be built.
(The reasonable way to use a build config script is to first configure
for all supported platforms, but only build the platforms/targets one
by one when you actually need them).
This currently prints:
--stdlib-deployment-targets STDLIB_DEPLOYMENT_TARGETS
The targets to compile or cross-compile the Swift
standard library for. None by default. Comma separated
list: android-aarch64 android-armv7 appletvos-arm64
appletvsimulator-x86_64 cygwin-x86_64 freebsd-x86_64
haiku-x86_64 iphoneos-arm64 iphoneos-armv7 iphoneos-
armv7s iphonesimulator-i386 iphonesimulator-x86_64
linux-aarch64 linux-armv6 linux-armv7 linux-i686
linux-powerpc64 linux-powerpc64le linux-s390x linux-
x86_64 macosx-x86_64 watchos-armv7k
watchsimulator-i386 windows-x86_64
This reorders the option list. It tries to categorise them by area and
then sort them alphabetically. This should help work through the list
and remove the now defunct options as well as try to reduce the set of
options into different build configurations that we can support and try
to organise the CMake invocations properly.
There is still a group of uncategorised options that should get sorted
out at some point. However, this is still a huge step forward towards
simplifying (and hopefully eradicating) this monstrous script.
