This new flag makes it easy to build Swift cross-compilation toolchains,
by disabling cross-compilation of all host tools, like the Swift
compiler and various macros, building on prior pulls #38441 and #82163.
Native compilation has more fine-grained flags like
`--build-swift-tools`, `--build-llvm`, and `--swift-testing-macros`, but
those will disable building them for _all_ platforms (with the exception
of `--build-swift-tools`, which I modified to only apply for the host,
since the initial introduction of this
`--cross-compile-build-swift-tools` flag a couple months ago), so
they're not suited for building a cross-compilation toolchain, where you
want all host tools built for the native host but not for any
cross-compilation SDKs.
FreeBSD isn't using toolchain files at the moment so this test is
failing. XFAIL'ing it on FreeBSD. If/when we do switch, the XFAIL should
fail, and we can re-enable it then.
This takes about twice as long to build in CI, but runs significantly
quicker (~22x). The exact time taken varies quite a bit between runs,
but this brings the worst-case overall run-time down from ~500s to
~200s. While here, make sure we pass `--skip-build` to the second
invocation to ensure we avoid building twice. Also disable using the
dependency cache since we want to test a clean build, and we just
want swiftpm to use the local deps.
LLVM-21 plans to remove the legacy method for building compiler-rt
in the same invocation as LLVM using `LLVM_ENABLED_PROJECTS` and
`LLVM_BUILD_EXTERNAL_COMPILER_RT`.
Support the new way of building compiler-rt with a new build-script
opt-in flag `--llvm-build-compiler-rt-with-use-runtimes` --
this will allow a staged introduction, and will ensure we can revert
back to the old behaviour temporarily in case of unforeseen regression.
Since this flag is meant to be short lived, in an attempt to keep the
logic simple we are gating on it only the
CMake cache entries that strictly control the compilation mode, all the
other entries used for configuring are added in both modes.
Take this chance to remove some stale code from `build-script-impl`, and
move some code in the generic CMake product to the LLVM one.
Addresses rdar://147505298
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.
It looks like in this configuration we need to convince `build-script`
we have `ninja` sources in the worktree.
Resolves#79256
Addresses rdar://144503319
This is a tool specifically designed to generate
Xcode projects for the Swift repo (as well as a
couple of adjacent repos such as LLVM and Clang).
It aims to provide a much more user-friendly experience
than the CMake Xcode generation (`build-script --xcode`).
This change introduces a new compilation target platform to the Swift compiler - visionOS.
- Changes to the compiler build infrastrucuture to support building compiler-adjacent artifacts and test suites for the new target.
- Addition of the new platform kind definition.
- Support for the new platform in language constructs such as compile-time availability annotations or runtime OS version queries.
- Utilities to read out Darwin platform SDK info containing platform mapping data.
- Utilities to support re-mapping availability annotations from iOS to visionOS (e.g. 'updateIntroducedPlatformForFallback', 'updateDeprecatedPlatformForFallback', 'updateObsoletedPlatformForFallback').
- Additional tests exercising platform-specific availability handling and availability re-mapping fallback code-path.
- Changes to existing test suite to accomodate the new platform.
Currently the test assumes that when we are testing for macOS we are
targeting the host architecture (since we need to reuse existing build
products to contain testing time) -- however there are some Apple
internal configurations in which that's not the case.
Addresses rdar://118337598
These builds do not work outside of darwin currently. Rather than adding
the skip to all the necessary build presets, just disable in the product
instead.
This is needed short term to allow the test to pass when running on
Python 3.11 and later and avoid errors like
```
<stdin>:44:1: note: non-matching line after previous match is here
<string>:1: DeprecationWarning: 'pipes' is deprecated and slated for removal in Python 3.13
^
```
Long term we want to replace uses of the obsolete `pipes.quotes`
function with `shlex.quotes`.
Addresses rdar://109664710
The current implementation currently requires to have physical machine
for each architecture supported by macOS, which is not desirable.
To allow all cases to be tested on a random Mac machine, allow
to inject an arbitratry current architecture into the inference
of the cross compile hosts by means of an environment variable.
Addresses rdar://99096874
Otherwise, we can't successfully dry-run a toolchain on darwin.
I added an option enable-extract-symbol-dry-run-test that can be set to restore
the previous behavior and updating the BuildSystem unit tests that depend on
that behavior to pass that flag.
It makes sense to just set this here since we aren't testing that functionality
and enables us to test this if we aren't using one of the specified Xcodes
(which can be useful).
