Use a structural definition of the settings and convert them to the
appropriate serialised format as a delayed operation. This makes it
easier to read the settings and modify them as we iterate on the
toolchain.
Take the opportunity to extract the PList conversion into a helper
function.
This further migrates towards a shared installation of the platform and
SDKs staging. This helps ensure that we are properly creating additional
SDKs without overwriting components and can share components across
builds. It also avoids unnecessary duplicated work.
* util: Add -Variant param to build.ps1 for building Asserts | NoAsserts.
* Special case BinaryCache path concatenation.
* Fix merge damage.
* Cleanup.
- Add FallbackLibraryPaths to usr/bin - swift-build uses this to lookup dlls like libclang
- Fill in the version field used to construct runtime library paths
The only currently known constraint on the build path is the compilers
build. Use long paths for the builds, co-locating more build products
and allowing better re-use of the build content. This makes it easier to
adjust the various targets that we are building without having to force
clean builds due to changes in the build mapping.
This adds the `swift_Concurrency` module to the new runtimes build. This
is sufficient to build the code but will require further fine tuning to
ensure that all the flags entirely identical and that the ABI surface is
also fully replicated.
The nightly toolchains on Windows improperly versioned the installation
to 6.0.0 (which would collide with an official 6.0.0 release 😱).
In order to use the toolchain as a pinned toolchain we need to account
for the path change. Add a workaround to allow using the extracted
toolchain snapshot.
This builds the static version of foundation in the experimental SDKs
for Windows. This is required to make further progress towards building
the early swift-driver with static linking to enable the early swift
driver based bootstrapping on Windows.
This sets up the Windows build for the new runtime build as a means to
ensure that we do not regress the build. In order to reduce overall
build times and to start experimenting with the static support, it
builds this runtime with static libraries. The intent is to produce a
complete static SDK for distribution.
The smoke test for the new runtime builds also serves as a static
runtime build test. Rename the `Foundation` product to
`DynamicFoundation` to permit the introduction of a `StaticFoundation`
to fit into the static SDK build.
The evolution proposal for enabling the memory allocator for the
toolchain on Windows has been accepted. Always use mimalloc for the
Windows toolchain and reduce the complexity.
Clean up and simplify some of the logic for the MSBuild based build of
mimalloc. Avoid building in the source tree at a cost of complexity.
Reduce the amount of building by selectively building projects instead
of the solution.
* [android] remove Android API level from Dispatch.swiftmodule names
* [build.ps1] use swift -print-target-info to determine module triple
* PR feedback
* fix comment
* add swift pinned toolchain to path before invoking swift.exe
* run swift.exe from the built toolchain instead of the pinned toolchain
* include pinned toolchain runtime in path
