The standard library (and other Swift modules built by our CMake build system)
has been building module files with an architecture only (e.g., x86_64.swiftmodule)
rather than a proper module triple (x86_86-apple-macosx10.15,
x86_64-apple-ios13.0-simulator, etc.), unlike every other build
system. There are hacks in the compiler and other tools to cope with
this unnecessary build difference. Fix the module file names so we'll
be able to remove the hacks later.
Fixes rdar://problem/49071536.
The build systems that drive Swift compilation have been using the
"simulator" environment as part of the increasingly inaccurately
named "target triple" to specify simulator targets for several
years... except our own hand-rolled build system. Identify
simulator targets and append "-simulator" to their target
triples.
Commit for CMake and build scripts to recognize OpenBSD. To keep this
commit relatively short, this just deals with the rather simple and
uncontroversial changes to the build system.
Note that OpenBSD calls "x86_64" as "amd64", Since the Swift stdlib will
be put in a subdirectory named after ARCH, to ensure the standard
library is properly found later, we use the native architecture name for
OpenBSD in the build system rather than trying to deal with the
difference the other way around.
Remove anachronistic check for a "blanket" module map in
/System/Library/Frameworks from Darwin SDK configuration. We already
extract other information from the SDK that we actually need, so check
for that directly instead.
Fixes rdar://problem/60084609.
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.
Now that CMAKE_HOST_SYSTEM_NAME and CMAKE_SYSTEM_NAME are set by default to
Android in the Termux app, make the needed tweaks. Some tests were adapted
to work natively on Android too, adds sys/cdefs.h to the Bionic modulemap,
and includes the start of native Android platform support in the build-script.
Check if building on Android through the ANDROID_DATA environment variable, then set
SWIFT_ANDROID_NATIVE_SYSROOT to the default layout for the Termux app, and key all the
include, lib, and other SDK paths off of that. The system libc and a few other libraries
are linked against from /system/lib[64]. Finally, check if lit is running natively on
Android and don't use adb if so.
This converts the local variable to a cached variable which the user can
specify. By making this a cached variable, it is easier to control and
ensure that a default value is provided.
Rather than hardcoding the paths to /usr/include, allow the user to set
the path to their libc headers. This is particularly important for
environments which may not use the traditional layout (e.g. exherbo) or
for builds which wish to build against an out-of-tree, non-system
installed libc for a Unix target which does not match the host system
(i.e. foreign cross-compilation).
This just reorders the printed order of the messages to be grouped
better. This will be further augmented in the next set of changes which
improve the cross-compilation setup that we have currently to allow for
foreign environments better.
The host value is used as part of the path to the tools. The NDK only
has Darwin, Linux, and Windows prebuilts. Enumerate the hosts fully and
record an error message otherwise.
The initial configure & generate of a build on Windows should have
the necessary VCVARS set in the environment. After that, we should be
incrementally building with those same vars to avoid conflicts between
Windows SDKs.
Cache these vars so that the same Windows SDKs are consistently used
in future incremental builds.
When building on case insensitive filesystems, there is no need to
create the library symlink forest as the paths will be resolved properly
due to the insensitivity. This avoids a bit of work and spew on
Windows.
The Windows SDK proides kernel32.Lib which on case sensitive file systems will
fail (due to the capital L in the extension). Workaround that by creating
symbolic links to handle this. This mirrors the technique used in LLVM.
Reduce some of the SDK configuration printing for non-Darwin
configurations. This simplifies the output and SDK configuration. The
parameter reduction simplifies the setup for cross-compilation.
The prefix and platform names are case adjusted values of the name of
the SDK. Compute the value rather than pass them down. The
simplifications will yield an easier cross-compilation implementation.
Rather than computing the triple first and passing it down to the SDK
configuration, hard code the triple into the SDK's configuration. This
is a value which is static and will allow us to configure
cross-compilation of the standard library for Linux. Although most
other targets do not support the same variety of architectures, this
enables those to be cross-compiled as well.
Remove the duplicated platform name parameter to the unix SDK
configuration.. This value is implicit currently and can be computed.
This needs to be computed to permit parallel co-installations of
architectures for targets which do not support fat binaries (i.e.
non-MachO targets).
The SDK is a sysroot. Permit the user to specify the location of the
SDK when building Linux. This is in preparation to cross-compile the
Linux standard library.
While we are exposing more control knobs to the user, we can start
simplifying `configure_sdk_unix`.
The SDK configuration can identify the triple for the android targets. This is
similar to the Windows behaviour. Doing so will now enable multi-architecture
builds!
The path to the SDK can be computed from the NDK. Do so to reduce the
parameters needed to pass to CMake. More importantly, this will allow building
with multiple architectures simultaneously.
The android specific configuration here is the same as the non-android in the
sense that it is setting up the triples for the target. Simply inline it as it
makes it more obvious what it is doing. This is preparatory work for adding
support for multiple architectures for Android.
ndk14 introduced "unified headers" which merged the headers for all
different API versions into one directory which effectively split the
"SWIFT_SDK_ANDROID_ARCH_${ARCH}_PATH" into two different directories.
Add include and library specific paths to various compilation and link
invocations across the Swift project to account for this change. Remove
some broken sysroot/sdk specific settings.
Report the ICU I18N and UC include paths and the library path. This
makes it obvious when the variable is not defined and more importantly
makes it easier to see what the paths are being used particularly when
cross-compiling for multiple architectures.
General purpose cross compilation from host x to targets a,b,c will
require the ability to have multiple architectures passed to
`configure_sdk_unix`. Simply change the function to accept multiple
archs.
Cross-compilation for multiple architectures & sdks require various
variables to be split to specify the arch/adk variant being focused on.
This change modifies various uses of the `SWIFT_SDK_${SDK}_PATH` to
`SWIFT_SDK_${SDK}_ARCH_${ARCH}`
Set the deployment target to an empty string for non-Darwin platforms
so that it is safe to append to the target triple without guarding it
with a check for Darwin.
This change leaves in place the use of -m*-version-min options, but
fixes the -target options to match. We can eventually remove the use of
the -m*-version-min options after everyone has moved to build with
versions of Clang that correctly handle the deployment version in the
-target option.
Windows ARM NT (the modern, non-Windows CE environment) is a pure thumb2
environment. The frontend does not canonicalise the target like in
clang. Ensure that we map the triple by hand to the desired target
triple.
Rather than use the `INCLUDE` and `LIB` environment variables to build
the Windows code, use the `UniversalCRTSdkDir`, `UCRTVersion`, and
`VCToolsInstallDir` variables. Using these we can compute the right set
of include directories and library search paths for the various
architectures. This will enable us to build multiple variants of the
Windows stdlib at the same time.
Additionally, rather than relying on the magic environment variables to
be processed by the driver, pass them explicitly to the driver through
the build system. This also is needed to allow parallel builds of
various architecture variants of the stdlib on Windows.
When cross-compiling for android ARM, it is possible that the system
linker does not support the target. However, in order to cross-compile
the target runtime, we need to adjust the linker to the target linker.
If one is not specified, fall back to the current behaviour of using the
system linker.
