Previously, Build script flag --clang-profile-instr-use is only used for building
clang and llvm. This patch extends PGO to the building of the Swift compiler.
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.
This flag '--swiftsyntax-install-prefix' could be used in the preset mode
to specify an installation dir. If we are building SwiftSyntax without building
the rest of the compiler, we'll install the SwiftSyntax modules and dylibs
with lib_InternalSwiftSyntaxParser.dylib to the given directory directly, ignoring
the conventional toolchain locations.
Previously, build-script-impl would set this to "" by default, resulting
in nothing being installed with --install-swift unless you explicitly
set --swift-install-components as well. Now we defer to cmake by
default.
On the cmake side, change the default value to exclude
* dev - uses a lot of disk space and usually not something you want to
install into a toolchain
* clang-resource-dir-symlink & clang-builtin-headers-in-clang-resource-dir -
these are mutually exclusive with clang-builtin-headers
* sourcekit inproc/xpc - these are currently mutually exclusive, so pick
the best one for the current platform.
This change makes build-script-impl use a new, shared version of swift-stress-tester’s build-script-helper.py which also supports building swift-evolve. It also adds the necessary flags and variables to build swift-evolve from build-script.
Build and install Foundation static. We now build Foundation using
CMake, which does not easily generate static and shared versions of
libraries. Create two builds to populate the toolchain
distribution.
build and install libdispatch static. We now build libdispatch using
CMake, which does not easily generate static and shared versions of
libraries. Create two builds to populate the toolchain distribution.
- Uses version 61.1 from ICU Github unicode-org/icu repository.
- Updates mixin_linux_installation to add libicu option.
- Use -j when building libicu.
- When buiding ICU, use --with-library-suffix=swift
This suffixes the ICU symbols with _swift.
The libaries are now named libicuucswift, libicui18nswift
and libicudataswift.
- Add the contents of uconfig.h.prepend into uconfig.h. This avoids
passing the renaming CFLAGS to swift and swift-corelibs-foundation.
Also resolves:
SR-5618: libicu compilation should happen in parallel respecting -j.
Support for Android aarch64 in many parts of the build-script. Most of
the changes are reuse variables/parameters that already existed for
Android ARMv7. There is also a new parameter to specify the ICU
data library, which is used by #19503.
With this one can build either armv7 or aarch64, since building both
at the same time requires more changes like #19432 (and probably
more work to support two set of paths).
Update the commands to use the CMake based output directory locations instead of
the legacy staging location. This will allow us to stop copying the files for
compatibility.
Pass along the configuration through the exported target for the standard
library. Still pass the compiler by hand to allow building libdispatch against
just a build of the standard library.
Prior to this, the swift build didn’t understand what i686 is, or what to do about building it. This unblocks building, but will still run into build breaks.
This should resolve SR-8826! Ideally, we would be using CMake to tie together
all the dependent packages and get proper dependency tracking. Currently,
change to the swift runtime do not get tracked properly, and can result in
undefined references to symbols.
