Unified builds of compiler-rt together with LLVM failed for the Android SDKs. It got too complicated to redirect the way LLVM would configure the nested build-trees. Standalone builds slightly increase build time, but they turned out much simpler and we end up with less duplication of definitions.
`LLVM_DEFAULT_TARGET_TRIPLE` was previously set to
`aarch64-apple-darwin` for Darwin Arm64 platforms. The correct value
should be `arm64-apple-darwin`.
Enable support for libxml2 on Windows to allow `llvm-mt` to be usable.
This then allows us to use `llvm-mt` as the manifest tool when building
for Windows. Remove the then obsoleted workaround of `-D CMAKE_MT=mt`.
This reduces the dependency on the MSVC toolchain and paves the path to
enabling the use of the manifest tool in SPM.
* [CMake] Give a dedicated component to compiler swift-syntax libraries
'compiler-swift-syntax-lib' so projects statically link to compiler
libraries (libAST etc) can use the required shared libraries.
rdar://135923606
* Update cmake caches
* Add back implicit `swift-syntax-lib` to `compiler` component for now
Some clients doesn't specify `swift-syntax-lib`.
`llvm-ml` is a replacement for `ml` which is the MSVC assembler. This is
useful on Windows and should be part of the distribution to ensure that
we have a complete toolchain.
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.
