The install-swift-driver phase knows how to build swift-driver using
CMake. Allowing only install-swift-driver without plain swift-driver
allows installing it without requiring swiftpm.
Support cross compile Xcode toolchain for Apple Silicon
* Add CMake flag DCMAKE_OSX_ARCHITECTURES to LLVM
* Add CMake flag DCMAKE_OSX_ARCHITECTURES to cmark
* Add CMake flag DCMAKE_OSX_ARCHITECTURES to lldb
* Add CMake flag DCMAKE_OSX_ARCHITECTURES to llbuild
* Add llbuild CMake options array to provide DCMAKE_OSX_ARCHITECTURES
* [Build System] Use one install package for cross compile hosts
* Remove Lipo before non-build-script-impl products
* Add support to only lipo without running installable package tests
* [Build System] Support cross compile install prefix for SwiftPM product in Swift Build Support
* Use cross compile toolchain path for indexstoredb and swift-driver
* Use cross compile toolchain path for swiftpm, swiftsyntax, swiftformat, and skstresstester
* Add cross compile toolchain support to Benchmarks, and fix the python lint issue in skstresstester.py
* [SwiftPM] Add support for cross-compile-hosts flag to build swiftpm using bootstrap script
Along with options to disable the mandatory clean using: `--skip-clean-swift-driver` and `--skip-clean-swiftpm`.
This will ensure that every invocation of build-script will, by default, clean up all build artifacts of these projects and re-build them from scratch.
This is needed for all builds because today arbitrary changes to the compiler can lead to us being unable to incrementally build components that are themselves written in Swift. This causes now-frequent failures in incremental build bots, and is a scenario that is encountered by developers. (For example see: rdar://65006593)
The proper long-term solution is to enable library evolution for these projects. Until this is done, the only safe thing to do is to always rebuild them.
Resolves rdar://65006593
These flags have done nothing for awhile, as 26 of 31 have already been moved to
build-script. Only the flags related to haiku, maccatalyst, and external-benchmarks
are unrecognized by either build script after this removal.
The added lines by Apple Silicon patch really depend on the build
machine platform and it forces that we can build stdlib only for
darwin targets. So I changed to allow non-darwin targets and filter only
unsupported darwin targets. This patch shuold be sent to upstream.
This product supports building and testing swift-format, forwarding the commands to a build script inside of swift-format's repo to handle actually invoking Swift PM. There are new command line options to support the swift-format product:
`--swiftformat`: Enables building swift-format.
`--skip-test-swiftformat': Disables running tests for swift-format after building.
Installing is intentionally not implemented because swift-format isn't ready to be installed as part of the Swift toolchain.
Add build-script command-line options for building, installing, and
testing swift-driver:
* `--swift-driver` will build the Swift driver. If testing is enabled,
it will be tested as well
* `--install-swift-driver` will install the `swift-driver` and
`swift-help` executables in the toolchain.
* `--skip-test-swift-driver` will disable testing of the Swift driver
when other tests are being run.
The Swift driver depends on SwiftPM to build; it is recommended that
you use `--infer` to get the appropriate dependencies built.
Note that this option does not yet replace the existing Swift driver
executables (`swiftc`, `swift`) with the new driver, nor does it
install the SwiftDriver library for use elsewhere.
This causes build-script to use the conservative dependency information that I
committed. When one uses this option, it is assumed that one wants to also
install all built products.
Some notes:
1. I included an extra --install-all option so without --infer enabled
one can enable this sort of install everything that we want to
build behavior.
2. I added %cmake as a lit variable. I did this so I could specify in
my build-system unit tests that on Linux they should use the just
built cmake (if we built cmake due to an old cmake being on the
system). Otherwise, the build system unit tests took way too
long. These are meant to be dry-runs, so building this cmake again
is just wasteful and doesn't make sense.
3. I unified how we handle cmark, llvm, swift with the rest of the
build products by making them conditional on build_* variables, but
to preserve current behavior I made it so that they are just
enabled by default unlike things like
llbuild/swiftpm/foundation/etc. This was necessary since previously
we would just pass these flags to build-script-impl and
build-script didn't know about them. Now I taught build-script
about them so I can manipulate these skip-build-{cmark,llvm,swift}
and then just pass them down to build-script-impl if appropriate
rather than relying on build-script-impl to control if these are
built.
Once this lands, I think we are at a good enough place with
build-script until we get rid of build-script-impl in terms of high
value QoI that will imnprove productivity. Once build-script-impl is
destroyed, we can start paring back what build-script itself does.
This is just based off of the defaults that we use on the buildbots as of this
commit.
In order to not break the bots as they are, I left the internal representation
as a semicolon list of components. So this should be NFC from the perspective of
the bots since they all explicitly specify llvm-install-components if needed
(and we do not install without install-llvm anymore).
This was already being done in a really hacky way namely, we computed the
build-script-impl list by filtering a single product list. But if one looked at
the actual product classes that we have, all of the build-script-impl products
are already a prefix of the entire original list?! So just repersent it as a
prefix/suffix pair.
I also put in an assert to verify we do not break this invariant in the future.
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.
The build scripts assume Android cross-compilation using the NDK, so avoid
that configuration if building on an Android host. Fix or disable some tests,
and don't install a glibc.modulemap without a native sysroot prefix.
This option configures the build directories without building any
targets. Splitting configuration from build allows for the decoupling
of build products. This decoupling is essential for the enlightened
way of developing Swift where the build-script is never actually used
to build anything, and build products can be independently
configured. When fully supported, this avoids many unnecessary
full/clean rebuilds and enables debugging by mixing-and-matching
configurations and rebuilding only select products after a change.
Sadly, the option has degraded, and a recent commit rendered it fully broken:
commit 34848e6026
Author: Alex Langford <apl@fb.com>
Date: Wed Jan 22 19:27:44 2020
[build] Unify logic to skip building projects in build-script-impl
The breaking commit was itself a reasonable cleanup. The underlying
problem was the original --skip-build was implemented using hacks that
conflated configuration with build.
This fix reinstates a reasonable situation:
--skip-build has no effect on configuration, as documented. It merely
skips building the targets. This is how it must behave to work as
intended.
--skip-build-{product} and its inverse --build-{product} controls
which products will be configured. These options are in heavy use
throughout the scripts, so changing the name (e.g. to --skip-config)
would be disruptive and of questionable benefit.
None of this changes the fact that any required build logic that
people have dumped into build-script-impl still effectively breaks the
enlightened way of building Swift, particularly when building
toolchain components.
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.
