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.
