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)
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.
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.
Currently we are using the same versions we use to build compiler and
standard library. This is an unnecessary coupling especially when
testing the generation of backdeployed executables for macOS -- here
we have interest in being able to run the tests on previous OSes, not
the compiler itself.
To support this, add new `--darwin-test-deployment-version-<platform>`
flags to build-script, which by default take the same value as the
matching `--darwin-deployment-version-<platform>` ones.
Addresses rdar://156724078
This allows testing Wasm stdlib without rebuilding WASI sysroot and stdlib, while some changes are still detected by ninja as dependencies and are rebuilt, which is great for local incremental builds.
This allows skipping the installation step and only building WasmKit, which is consistent to how other products are handled by `build-script`, where they have separate `--install` options. Existing behavior is preserved, where passing `--wasmkit` alone will install it, but now `--wasmkit --install-wasmkit false` will skip its installation step.
If you use SwiftStdlibCurrentOS availability, you will be able to
use new types and functions from within the implementation. This
works by, when appropriate, building with the CurrentOS availability
set to the current deployment target.
rdar://150944675
Use it in the linux CI presets to set them to Debug mode and speed up
the linux CI, plus add a new preset which keeps building them in Release
mode.
I was looking at a passing linux CI run and saw the log timings at the
end: it takes [longer to build and test the swift-foundation repos than
to compile all 7k+ mostly C++ files in
LLVM](https://ci.swift.org/job/swift-PR-Linux/18996/console)!
```
--- Build Script Analyzer ---
Build Script Log: /home/build-user/build/.build_script_log
Build Percentage Build Duration (sec) Build Phase
================ ==================== ===========
9.2% 1132.94 Running tests for foundationtests
9.1% 1120.57 linux-x86_64-swift-build
9.0% 1104.2 Building llvm
7.2% 878.84 Running tests for swiftfoundationtests
6.5% 796.81 Running tests for swiftpm
5.6% 684.7 Building swiftpm
5.5% 667.92 linux-x86_64-swift-test
4.9% 597.64
```
Looking at the log, building swift-foundation in release mode takes a
long time, so let's see if changing it to debug mode helps. Some
background - the Foundation repos are built twice on the linux CI: once
by CMake, which is the version installed in the toolchain, then a second
time by SwiftPM purely for testing.
This pull only affects that second SwiftPM build for testing, which is
not shipped in the final toolchain but thrown away.
The existing swift-cmake-options flag overwrites all flags computed by
build-script. Sometimes it is useful to be able to append additional
CMake flags without overwriting the existing flags.
This patch adds `--extra-swift-cmake-options` that adds the specified
flags to the Swift CMake configuration instead of overwriting them.
This also adds a similar `--extra-llvm-cmake-options`, which adds the
new flags to the end, allowing one to replace and overwrite CMake flags
that build-script computed.
Due to the parameter passing mechanisms in build-script-impl, while this
behavior would be useful for Swift, it is not immediately apparent how
one would best implement this at this time.
LLVM-21 plans to remove the legacy method for building compiler-rt
in the same invocation as LLVM using `LLVM_ENABLED_PROJECTS` and
`LLVM_BUILD_EXTERNAL_COMPILER_RT`.
Support the new way of building compiler-rt with a new build-script
opt-in flag `--llvm-build-compiler-rt-with-use-runtimes` --
this will allow a staged introduction, and will ensure we can revert
back to the old behaviour temporarily in case of unforeseen regression.
Since this flag is meant to be short lived, in an attempt to keep the
logic simple we are gating on it only the
CMake cache entries that strictly control the compilation mode, all the
other entries used for configuring are added in both modes.
Take this chance to remove some stale code from `build-script-impl`, and
move some code in the generic CMake product to the LLVM one.
Addresses rdar://147505298
Instead of using `--build-ninja` to decide to build ninja, build it
automatically if a sufficiently new enough version is not available.
Also record the build time taken to build the local Ninja so that we can
see how much time we would save by stashing a pre-built Ninja in CI.
What is nice about this is that by not using extra-cmake-args, we can avoid
passing this into LLVM as well when attempting to reproduce failures on the bots
(thus avoiding having to rebuild LLVM as well).
I have been doing this using extra-cmake-args/etc... just feels better to have
an actual option to do this.
Just did this quickly while waiting for my Linux build to finish that uses
extra-cmake-args to set the linker.
This was quite brittle and has now been superseded
by swift-xcodegen. Remove the CMake/build-script
logic for it, leaving the option behind to inform
users to switch to using xcodegen instead.
* Reapply '[BuildSystem] Stop building for i386-watch-simulator (#77692)'
* [BuildSystem] Stop building for i386-watch-simulator
In Xcode16 it is not supported.
This initially broke client projects who were still building the legacy
architecture but now that's resolved.
Move the backtracing code into a new Runtime module. This means renaming
the Swift Runtime's CMake target because otherwise there will be a name
clash.
rdar://124913332
