This doesn't really add much to readability and is almost always
`default`. Simply assume the default behaviour and allow callers
to alter the behaviour if needed.
Adjust the build invocation for swift-corelibs-foundation to account for
changes required for building for android after re-coring the library.
We use the SDKRoot to find the necessary libraries.
Sets `CMAKE_POSITION_INDEPENDENT_CODE=YES` when building libxml2 and
curl. This causes `-fPIC` to be passed to clang when compiling, which is
required for the i686 Android build to succeed.
This change makes `build.ps1` consistent with the Python build files
swift_build_support\products\libxml2.py and
swift_build_support\products\curl.py, which already define this cmake
property. It is already propertly set for zlib in both locations.
This renames the `Build-*` phase associated with building swift-testing.
Rather than name it `Build-SwiftTesting` match the other functions and
name it `Build-Testing`.
The Android NDK is being extracted with an extra intermediate directory:
$BinaryCache\android-ndk-r26b\android-ndk-r26b
The Android build fails because it expects the NDK contents to live
immediately under the directory:
$BinaryCache\android-ndk-r26b
The extra android-ndk-r26b sub-dir comes from the NDK zip archive
itself, which we have no control over. To work-around, allow callers
of Extract-ZipFile to control whether or not it should create the
extraction sub-dir. Override the default behavior for NDK extraction
only.
In Build-FoundationMacros, use the build Swift SDK for the build case
and when cross-compiling, use the swift syntax build from the build
arch binary cache as opposed to the host arch binary cache or else the
architecture mismatch will happen.
Build the testing macros early along with the Foundation macros and then
build a copy for distribution as well. This brings testing macros in
line with the Foundation macros.
This is required so that we can use a custom pinned toolchain. The three
arguments required are:
- `PinnedBuild` (URL to toolchain)
- `PinnedSHA256` (SHA256 for installer)
- `PinnedVersion` (toolchain version)
Prior to this, we would error out as `PinnedVersion` would be unset and
could not be specified as it was not an argument.
With the introduction of swift-toolchain-sqlite, we have a version of
SQLite that we can use to build the toolchain. Prefer this over the
fetched amalgamation which simplifies the logic for the toolchain and
ensures that we are able to track this as a regular component.
* Basically following XCTest scheme.
* Build TestingMacro separately from Testing library and install it to
the toolchain's `bin`
* Testing swift-testing itself is TODO
In `Build-CMakeProjects` function, when `$InstallTo` is not an empty
string, `install` target is automatically built. Specifying `install` in
`$BuildTargets` makes it built twice.
This tweaks the build configuration for the runtime to downscope what we
actually build to what we require. This should have a negligible
improvement to the build times.
in CI
https://github.com/swiftlang/swift/pull/75073 has broken a local
toolchain build on windows using build.ps1,
as the local build does not use update_checkout on windows, and
thus does not checkout swift-corelibs-foundation-windows.
We need a bootstrapping toolchain. Now that we have an ARM64 build for
Windows, pin that to provide a default pinned toolchain. This should
allow us to build natively on Windows ARM64 without having to specify
the download image ourselves.
