Currently, passing `--wasmkit` to `build-script` also requires `--swiftpm --install-swiftpm` and all of their dependencies (at the very least Dispatch, Foundation, XCTest, Testing, llbuild, swift-build). We can conditionally switch to host SwiftPM when new SwiftPM is not built or installed.
Currently, passing `--wasmkit` to `build-script` also requires `--swiftpm --install-swiftpm` and all of their dependencies (at the very least Dispatch, Foundation, XCTest, Testing, llbuild, swift-build). We can conditionally switch to host SwiftPM in this case.
We currently rebuild swift-syntax, swift-foundation-icu and swift-foundation twice: Once to test swift-foundation and once to test swift-corelibs-foundation. Using a unified build for both projects means that we only need to rebuild them once, saving ~5 minutes.
(cherry picked from commit 61f833c04c)
Organise the build options which have grown organically. We have a
number of options that are co-dependent but were spread apart. Ideally,
we would like to minimise the options. There are a number of "options"
which are less so user-configurable options but rather options to allow
migration (e.g. python version, sccache version). There are some options
which are temporary and would be ideal to simply drop at some point
(`IncludeDS2` should always be true, `IncludeNoAsserts` should
become toolchain variants to build, and `FoundationTestConfiguration` is
meant to be a CI configuration).
Introduces a new build-script flag `--test-optimize-none-with-opaque-values`
and build targets like `check-swift-optimize_none_with_opaque_values` that
runs the execution_test's while compiling them with -enable-sil-opaque-values.
This mode is quite useful while working to bring-up opaque values.
Strip the `swift-` prefix and the `-a-windows10` suffix on the
toolchain. This allows us to get back within the path limits which
otherwise prevents extracting the experimental SDK.
This allows us to use a specific SDK from the pinned toolchain image. By
enabling this functionality, we can migrate towards a newer snapshot and
build the early swift-driver.
Introduce a new build product: `CDispatch`. This is a dynamic variant of
libdispatch and BlocksRuntime. This breaks the cycle of the Swift
runtime and dispatch. This should also allow us to simplify the
toolchain build.
We currently rebuild swift-syntax, swift-foundation-icu and swift-foundation twice: Once to test swift-foundation and once to test swift-corelibs-foundation. Using a unified build for both projects means that we only need to rebuild them once, saving ~5 minutes.
This new flag makes it easy to build Swift cross-compilation toolchains,
by disabling cross-compilation of all host tools, like the Swift
compiler and various macros, building on prior pulls #38441 and #82163.
Native compilation has more fine-grained flags like
`--build-swift-tools`, `--build-llvm`, and `--swift-testing-macros`, but
those will disable building them for _all_ platforms (with the exception
of `--build-swift-tools`, which I modified to only apply for the host,
since the initial introduction of this
`--cross-compile-build-swift-tools` flag a couple months ago), so
they're not suited for building a cross-compilation toolchain, where you
want all host tools built for the native host but not for any
cross-compilation SDKs.
With the last changes to the C++ interop support in the new runtimes
build, the default on Windows matches what it is on Apple platforms.
Explicitly opt into the C++ overlay build on Windows.
