This was quite brittle and has now been superseded
by swift-xcodegen. Remove the CMake/build-script
logic for it, leaving the option behind to inform
users to switch to using xcodegen instead.
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.
Add libclang to install_components_with_clang presets
Swift Build uses libclang to read serialized diagnostic files, and invoke the module dependency scanner. Add it to the toolchain build.
When adding a Swift Testing test to Swift PM repository, the `test`
portion of t he OSX package pipeline was building against x86_64 and
arm64.
Ensure Swift PM testing only runs against the host platform
architecture.
The main goal of this change is to ensure that the new build of the
stdlib matches the same level of verbosity of the compiler build that
spawn it.
For now I'm not matching this behaviour to the regular CMake build
products (which would be needed if want to target external projects
configured in LLVM).
Addresses rdar://144256800
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.
BTI enforcement is mandatory, which means if PAC and BTI instructions
are not emitted, then the compiled binary gets killed with SIGILL. The
platform default compiler achieves enabling PAC and BTI by embedding the
relevant enabled Clang compilation option flags into the local platform
toolchain, which affects C/C++ code generation.
For Swift however, to achieve the same effect, we would need to add the
relevant LLVM module flags in the IRGen process. But, since Swift uses
the Clang code generator when doing this, using the same option flag
approach will work here as well, and is probably preferable to
introducing operating system-dependent logic to the ClangImporter, for
example.
Finally, the stdlib needs to be built with PACBTI as well, since the
stdlib's global constructors get run when a compiled binary does. Since
the Swift build uses the just-built Clang for the stdlib, just embed the
necessary options into `CMAKE_C_FLAGS` and `CMAKE_CXX_FLAGS` via
`build-script-impl`. This will be redundant with the host compiler, but
at least it will be thorough.
* Reapply '[BuildSystem] Stop building for i386-watch-simulator (#77692)'
* [BuildSystem] Stop building for i386-watch-simulator
In Xcode16 it is not supported.
This initially broke client projects who were still building the legacy
architecture but now that's resolved.
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
These were isolated by interleaving operations. However, recent tweaks
to the build have removed those. Merge the adjacent sections to show the
contiguous build segment.
Build bot runtimes are very long and not fully transparent right now. In addition to the steps for build and test, we should keep an eye on Fetch-Dependencies.
Batch dependency scanning was added as a mechanism to support multiple compilation contexts within a single module dependency graph.
The Swift compiler and the Explicitly-built modules model has long since abandoned this approach and this code has long been stale. It is time to remove it and its associated C API.
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.
