This allows us to build swift-format with dynamic linking against the
toolchain build of the swift-syntax and swift-argument-parser packages.
Wire up the swift-markdown build and hoist the swift-format build prior
to sourcekit-lsp. This sets us up for supporting swift-format based
formatting in the LSP.
Windows builds in waves:
- build build tools
- build tools (compilers, debuggers, linkers, assemblers)
- build runtimes (Swift runtime, standard library, experimental libraries)
- build core libraries
- build Swift tooling
We do not need to build the C++ interop module at the moment when
building the tools. This disables that and the extra content which
currently does not result in any artifacts.
This is the start of the removal of the C++ implementation of libSyntax
in favor of the new Swift Parser and Swift Syntax libraries. Now that
the Swift Parser has switched the SwiftSyntaxParser library over to
being a thin wrapper around the Swift Parser, there is no longer any
reason we need to retain any libSyntax infrastructure in the swift
compiler.
As a first step, delete the infrastructure that builds
lib_InternalSwiftSyntaxParser and convert any scripts that mention
it to instead mention the static mirror libraries. The --swiftsyntax
build-script flag has been retained and will now just execute the
SwiftSyntax and Swift Parser builds with the just-built tools.
SWIFT_STDLIB_SINGLE_THREADED_RUNTIME is too much of a blunt instrument here.
It covers both the Concurrency runtime and the rest of the runtime, but we'd
like to be able to have e.g. a single-threaded Concurrency runtime while
the rest of the runtime is still thread safe (for instance).
So: rename it to SWIFT_STDLIB_SINGLE_THREADED_CONCURRENCY and make it just
control the Concurrency runtime, then add a SWIFT_STDLIB_THREADING_PACKAGE
setting at the CMake/build-script level, which defines
SWIFT_STDLIB_THREADING_xxx where xxx depends on the chosen threading package.
This is especially useful on systems where there may be a choice of threading
package that you could use.
rdar://90776105
Update the toolchain configuration to disable the python home embedding.
This should allow us to be more freestanding of the python location and
give us better control of the python library being used.
This is useful for restoring the Windows ARM64 port of the runtime.
This currently does not build due to issues in the module.map
definitions causing a build failure. However, adding the file enables
others to reproduce the build and help.
This adds a CMake cache for the Windows ARM64 toolchain. It is possible
to build and run the toolchain on ARM64, though we have not had regular
releases of the toolchain. This adds the cache used to generate the
toolchain in the hopes that it is useful for others and that we can soon
get more regular ARM64 toolchain builds.
This adds a cache for a configuration of the standard library for
Windows x86 configurations. This should help restore the x86 builds of
the SDK for Windows.
Add the default target triple to match the target for the Windows
toolchain. This avoids the need for an additional parameter, and
it makes sense for the target to be the host by default. Explicit
parameters can change the target when desired.
The official builds include the profiling library, so we should enable
it on the CI to ensure that the path is tested. This should only add
~1m to the total build time.
This allows configuration of a build for just the runtime/SDK components
rather than a complete toolchain. It allows for more effective
iteration when working on just the runtime aspect of the toolchain.
