Support the usual `--enable-*san options`, but also add a
`--test-indexstore-db-santitize-all` that runs the tests once for each
sanitizer. Sanitizing just indexstore-db with a regular toolchain should
be much faster than using sanitized compilers.
Now that the autodifferentiation support is being upstreamed, add an
option to enable building the TensorFlow swift-apis package optionally.
This enables easier development cycles for the engineers working on it.
This migrates the playground support out of the build-script-impl and
into the python based build system. This makes it build more similarly
to the Swift Package Manager and SourceKit-LSP. More importantly, it
reduces the dependency on build-script-impl.
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.
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.
SwiftSyntax is not part of the standard library and thus should not be
installed in usr/lib/swift.
This also removes the code to install SwiftSyntax's .swiftmodule file
since that code path was never exercised.
Add `--enable-experimental-differentiable-programming` build-script flag.
The build-script flag enables/disables standard library additions
related to differentiable programming. This will allow official Swift
releases to disable these additions.
The build-script flag is on by default to ensure testing of
differentiable programming standard library additions. An additional
driver flag must be enabled to use differentiable programming features:
https://github.com/apple/swift/pull/27446
The --dump-config option prints a recursive JSON dump of the BuildScriptInvocation object’s properties, which gives access to essentially all of the knowledge build-script has about the build before it starts performing it. This makes the output more flexible and extensible without severely convoluting the implementation, but doesn’t really give us a stable representation of that data.
If passed, build-script doesn’t build anything; it just prints the full path to the directory the invocation would have built its products in. This is intended to allow you to build tools which take build-script options like --debug and --xcode and use them to determine the build directory you’re currently using.
Build a separate compiler-rt instance for running the tests. It is built
and tested against an installed toolchain instead of the llvm-build-dir.
Install everything we need to run tests (CMake modules, FileCheck, etc.)
into the toolchain directory.
Add synthetic target 'all' for llvm-install-components. Also we must set
LLVM_INSTALL_UTILS=ON, so the utilities required by tests (e.g.,
FileCheck) are included in the install target.
Now one can on Darwin/Linux build the benchmarks via swiftpm from build-script by passing in:
```
build-script $NORMAL_ARGS --install-swift --install-swiftpm --install-llbuild --toolchain-benchmarks --swiftpm --llbuild
```
This is done using the infrastructure that BenL added for sourcekit-lsp.
The manipulation of host-test and skip-android-host was a little
different than the equivalent skip-ios-host and similar variables. These
changes make them closer and allows executing only the compiler tests,
but skip the test that need an Android device to run.
- Disables the upload command of the tests if the subset is the
non-executable tests. The non-executable test do not need to be
uploaded, and in the case of Android, a device doesn't need to be
connected, so trying to connect to one will fail.
- Fix a problem where the swift_interpreter feature was removed without
first checking if it was really added.
- Only enable the host tests (the compiler tests) in the Android CI
preset (there's no device attached to that server, but currently only
the Linux tests were being executed, which doesn't make a lot of
sense).
- Move the decision about which platform support device/host tests into
the platform themselves, which allows Android to have device/host
tests. Also modify a little bit the logic around enabling/disabling
the test suite to allow running only the host tests of a platform.
- Fix the suffix name for the target of non-executable tests in a couple
of places.
I have been meaning to do this change for a minute, but kept on putting it off.
This describes what is actually happening and is a better name for the option.
We need to decide if we want to support these configurations, and in the
meantime it's better for us to disable them while we stabilize on the
other platforms. Fixes the currently broken build on 14.04.
Now we build libcxx if and only if --libcxx is passed, like with other
optional products. This loses the intended "build if sources are
checked out" behaviour, but behaves more predictably.
Add support to build-script to build and test the indexstore-db and
sourcekit-lsp projects. A future change will add support for installing
these products and putting them in the toolchain. To build the new
products, add the `--sourcekit-lsp` or `--indexstore-db` options to a
`build-script` invocation.
We add the notion of a Product that is not part of build-script-impl and
build these products after the install phase of build-script-impl. These
products are built using the installed toolchain - either using the
default location within the build subdirectory, or the user-specified
`--install-dest`. This is somewhat rigid setup, since it requires the
toolchain used to build to be the same as the final installed toolchain
(if any), but it makes for a simpler change to the existing builds while
still making progress towards a toolchain-based build model.
*Note*: currently, if you are not using a preset you will need to
manually specify all of the dependencies (on macOS this is
swiftpm and llbuild, on other platforms you additionally need
libdispatch, icu, foundation, and xctest), and the install flags for the
same projects (`--install-llbuild --install-swiftpm ...`). This is not
particularly user-friendly, but it matches the current behaviour of the
other targets, and there is not yet any infrastructure in build-script
to describe these dependencies.
Turns on the `--no-legacy-impl` option to build-script by default; the
old behaviour is temporarily still available as `--legacy-impl`.
This causes build-script to invoke build-script-impl for every
individual build/test/install/etc. action rather than a single global
invocation. For example, a single invocation might be for
`macosx-swift-install`. This will enable the python code in build-script
to drive the overall process and add additional steps in between actions
without the involvement of build-script-impl. It also provides a path to
refactoring the existing actions out of build-script-impl individually.
Discussed as part of https://forums.swift.org/t/rfc-building-swift-packages-in-build-script/18920
The --no-legacy-impl flag was originally disabled by default because of
concerns about the performance of null builds due to the increased
number of script invocations. There is a small optimization in this
commit to use `tr` when processing command-line options instead of
bash's builtin substitution, which eliminates most of the overhead.
After this change, a null build of llvm+swift changes from 1.6 s to
2.1 s on Linux, and from 5 s to 6 s on macOS. Non-null builds and
builds that involve more build products than just llvm+swift (e.g.
corelibs) are basically unaffected since they are not correctly
incremental to begin with.
The changes to build-script-impl in this commit are to fix the behaviour
of --no-legacy-impl, which had bitrotted since it was introduced. These
changes are to make various parts of the script not rely on variables
defined in "earlier" parts of the script, which is good hygiene in
general.
