If things crash very early on, build-script tries to divide by zero when
computing the percent time spent in each project because the build time
is zero. While this is a failure state, all it does is add more output
to the crashing stack trace.
The tests broke on the community Android CI since #82325, and I just
noticed the install issue when cross-compiling Testing with a
freshly-built compiler, which I'd never done before. Also, fix the NDK
path shown in the CMake output.
The build support Python libraries assume by default that if we do not
supply a Swift toolchain path, we can find clang in the installed
toolchain path: i.e., the clang that we just built. However, possibly
during bootstrap, we may not have a preexisting Swift compiler but still
want to use the clang on the platform that is already installed.
build-script already gives us native-clang-tools-path. Here, we plumb
this through to the relevant Python modules. If the
native-clang-tools-path is not specified, we use the
install_toolchain_path, just like native_toolchain_path, and the
existing behavior is effectively unchanged. If we do specify a
native-clang-tools-path, then we return it to ensure that we properly
refer to the clang that lives there instead of always defaulting to the
just-built clang.
Added optional `ignore_extra_cmake_options` to `cmake_product.py`, existing behavior is preserved with the default argument value set to `False`.
Passed `ignore_extra_cmake_options=True` in `wasisysroot.py`. This allows libc++ for WASI to be built correctly with `-fno-exceptions` in presence of `extra-cmake-options` in macOS presets (which are absent in Linux presets).
Otherwise the build will fail if we pass `--no-llvm-include-tests` or we
set directly `LLVM_INCLUDE_TESTS` directly to `FALSE`/`OFF`
Addresses rdar://153562845
While LLVM cannot be completely disabled when Swift or LLDB are built, we should still allow skipping LLVM configuration and build steps when Swift and LLDB are not built. This can happen, for example, when `build-script` user wants an ad-hoc incremental build with `--skip-build-swift` and `--skip-build-lldb` for products that don't depend on LLVM and Swift, or if LLVM and Swift were already configured and built in previous `build-script` invocations.
Since 5f2b0022d1, swift-testing is being
compiled with WMO, which removes some of inter-object references in
object files by DCE. The inter-object reference removal revealed a
long-standing issue that the runtime metadata sections of objects in an
archive are not always included in the final binary if symbols from
those objects are not referenced anywhere. To force including all
metadata sections in the final binary, we have to emit everything in a
single object file when building the archive.
This issue happens only for Wasm SDK, which ships swift-testing as a
static archive.
Passes the value of the environment variable `TOOLCHAIN_VERSION` through
to Swift's `SWIFT_TOOLCHAIN_VERSION` for use in eg.
`-print-target-info` (and some day, `--version`).
The 64-bit ARM architecture spelling on FreeBSD is aarch64, not arm64.
This results in a build failure about a missing
`freebsd/arm64/swiftrt.o` while building the runtimes.
This tells build-script to build Swift-testing with WMO.
This results in a faster build products, but is also necessary for
configurations using the legacy swift driver, which would emit an
invalid swift interface in non-WMO builds.
Fixes: rdar://151357567
...we disabled in #81354
This requires a couple of supporting changes
* under Linux, do not cross compile LLVM when building for the host
architecture -- that will ensure that the compiler-rt build will use
the just built compiler and not the system one (which may not be
new enough for this purpose);
* provide sanitizer flags depending on the linker the just built compiler
will use -- this detection is brittle, so print a message advising the
user how to override this.
Addresses rdar://150849329
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
This enables `swift run` and `swift test` to use WasmKit when cross-compiling to Wasm with Swift SDKs that have toolsets pointing to WasmKit.
rdar://150382758
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.
We build CMake on all platforms (except Darwin for an unknown reason) if CMake is not preinstalled. Since CMake 4.0 regresses certain build configurations, there's currently no way to build on Darwin without installing an older CMake version 3.x manually. This can be simplified if we build a pinned version of CMake consistently on all platforms.
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
WASI with Embedded Swift provides WASI-libc and libc++ headers necessary to build the `_Concurrency` module for Wasm. We now add `wasm32-unknown-wasip1-wasm` triple to `EMBEDDED_STDLIB_TARGET_TRIPLES` when `SWIFT_WASI_SYSROOT_PATH` is set, which builds the necessary stdlib slice.
---------
Co-authored-by: Yuta Saito <kateinoigakukun@gmail.com>
If the directory where the build time log is supposed to go doesn't
exist, create it. The append file mode will create files, but won't
create directories. When we start building ninja, we haven't necessary
created the build directory yet, so this results in an error about the
missing directory when writing the build time log.
The ninja builder took a host argument that was unused by the function.
The ninja build failed to pass this argument, resulting in
an execution failure. Removing the argument.
