Currently, when trying to build with the latest stable Xcode, you get this error:
```
using unsupported Xcode version:
Xcode 13.2.1
Build version 13C100
```
Xcode 13.2.1 can successfully build the toolchain and should be marked as supported.
This changes build-swift script shebang to use Python 3 explicitly. The
code is already compatible and functional with python3, so this removes
any implied backward compatibility, and removes any ambiguity based on
the user's current environment, especially since some systems, like
macOS, still link 'python' to Python 2.
This also removes the now unnecessary 'from __future__' imports, and the
'six' module, which is only necessary for python2 compatibility.
This shrinks the number of lines in build-script by 50% and just makes it easier
to read. It will also enable me to refactor parts of it into pieces without
touching the main build-script file. This is really library code... build-script
itself doesn't care about how BuildScriptInvocation is actually implemented
under the hood.
Pass the Swift and CMake flags needed to cross-compile Foundation and so on, with
the first example of Android. Add a new flag, --cross-compile-deps-path, which is
used to search for cross-compiled libraries, like libcurl, that the corelibs
depend on. Also add a new flag, --common-swift-flags, to pass additional Swift
flags to the corelibs.
In the original implementation (https://github.com/apple/swift/pull/36377), using `--infer` accidentally disables the `earlyswiftdriver` product (`before_impl_product_classes` set to always empty). This change fixes that and makes sure early SwiftDriver is always built, regardless of whether or not `--infer` is used.
This change also ensures that `install_all` setting triggered by `--infer` does not affect products which specify `is_ignore_install_all_product` to return True. This is useful for products which should not be installed into the toolchain (corresponding build products that use the just-built toolchain are the products that get installed, e.g. `swiftdriver` to `earlyswiftdriver`).
This would be needed to reduce overall build times in scenarios when
generating symbols for all binaries is too expensive and/or not needed.
At the same time, introduce tests around the logic that handles symbols.
Addresses rdar://76865276
This would be needed to reduce overall build times in scenarios when
generating symbols for all binaries is too expensive and/or not needed.
Addresses rdar://76865276
This will make sure that compiler developers are using the new driver when they build the compiler locally and use it.
- Adds a new build-script product category: before_build_script_impl for products we wish to build before the impl products.
- Adds a new EarlySwiftDriver product to that category, which gets built with the host toolchain.
- Adds an escape hatch: --skip-early-swift-driver
- Adjusts the swift CMake configuration with an additional step: swift_create_early_driver_symlinks which (if one was built) creates symlinks in the swift build bin directory to the EarlySwiftDriver swift-driver and swift-help executables.
- Adds a new test subset : only_early_swiftdriver, which will get built into a corresponding CMake test target: check-swift-only_early_swiftdriver-* which runs a small subset of driver-related tests against the Early SwiftDriver.
- This subset is run always when the compiler itself is tested (--test is specified)
- With an escape disable-switch: --skip-test-early-swift-driver
- All tests outside of only_early_swiftdriver are forced to run using the legacy C++ driver (to ensure it gets tested, still).
NOTE: SwiftDriver product (no 'Early') is still the main product used to build the driver for toolchain installation into and for executing the product's own tests. This change does not affect that.
This is meant to support scenarios in which we need to build as little as
LLVM as possible for performance reasons (e.g. when enabling LTO).
While LLVM CMake build system offers options in this sense,
in our investigation they turned out not to be suitable,
since either they are not granular enough (`LLVM_INCLUDE/BUILD` flags)
or they require active opt out for any new tool added
(`*_BUILD_*_TOOL` flags)
When using this mechanism, there is the possibility to specify different
targets to use for cross-compile hosts.
Supports rdar://32019390
Introduce a new parameter `--skip-llbuild-clean` to prevent this from
happening.
This mimicks similar logic in place for `swiftpm`, `swift-driver`
(#33563) and `xctest` (#19512)
Addresses rdar://75057069
Sometimes with the --sccache flag passed to build-script, the first
round of compiler invocations will time-out waiting for the sccache
server to start. Here we ensure the server is started ahead of time
to avoid this failure.
Resolves rdar://74951999
* [Concurrency] Build C only libdispatch before Swift on non-Darwin platforms
_Concurrency depends on libdispatch and since it is not available by
default on non-Darwin platforms, it needs to be built before the Swift
project, so that the dependency can be resolved.
* Fix clibdispatch installation and BuildSystem tests
* Fix build system tests on Darwin and formatting
This is meant to support parallel CI runs on the same Linux bot, so that
they don't share the module cache and reduce (hopefully) the likelihood
of issues related to invalid signatures.
When the option is enabled, the environment variable `XDG_CACHE_HOME`
is explicitly set in `build-script` and should be inherited by all the
child processes.
Currently we don't check the operating system before setting the
variable (since it should be a noop for other OSes).
Addresses rdar://73887745
This should enable scaling when using machines with large amount of
RAM.
To better support machines with lower spec, process one binary per
dsymutil invocation (reverting #34149).
Add some (limited) facilities to gather the time taken to execute
dsymutil to better assist in tuning the parameter -- these are printed in
JSON format in the log to allow for easier scraping
```
{ "command": "dsymutil", "start": "2020-11-18T18:10:47" }
{ "command": "dsymutil", "end": "2020-11-18T18:14:45" }
```
Addresses rdar://71018443
