Teach build-script to print the list of valid targets for the
--stdlib-deployment-targets option. Unfortunately, passing all
supported targets to this option is the only way to force
configuration of those targets. Simply using --ios is no longer
sufficient--none of the iOS targets are actually configured unless you
ask them to be built.
(The reasonable way to use a build config script is to first configure
for all supported platforms, but only build the platforms/targets one
by one when you actually need them).
This currently prints:
--stdlib-deployment-targets STDLIB_DEPLOYMENT_TARGETS
The targets to compile or cross-compile the Swift
standard library for. None by default. Comma separated
list: android-aarch64 android-armv7 appletvos-arm64
appletvsimulator-x86_64 cygwin-x86_64 freebsd-x86_64
haiku-x86_64 iphoneos-arm64 iphoneos-armv7 iphoneos-
armv7s iphonesimulator-i386 iphonesimulator-x86_64
linux-aarch64 linux-armv6 linux-armv7 linux-i686
linux-powerpc64 linux-powerpc64le linux-s390x linux-
x86_64 macosx-x86_64 watchos-armv7k
watchsimulator-i386 windows-x86_64
SwiftSyntax is not part of the standard library and thus should not be
installed in usr/lib/swift.
This also removes the code to install SwiftSyntax's .swiftmodule file
since that code path was never exercised.
The Android CI build only builds the stdlib because the rest of the
components are build for the host, which is not very useful, since they
are already tested in other CI configurations.
Add `--enable-experimental-differentiable-programming` build-script flag.
The build-script flag enables/disables standard library additions
related to differentiable programming. This will allow official Swift
releases to disable these additions.
The build-script flag is on by default to ensure testing of
differentiable programming standard library additions. An additional
driver flag must be enabled to use differentiable programming features:
https://github.com/apple/swift/pull/27446
[Build System: build-script] Update the --stdlib-deployment-targets flag to no longer append from multiple uses, instead use the standard last-wins strategy.
- Forward several environment variables to the test environment because
Windows uses them to inform the processes about things like the number
of processors and the architecture.
- Normalize some literal Unix paths to be the same as the results in
Windows, that will have forward slashes and the drive letter.
- Skip some test that use build-script-impl and tests that check for
files being executable (everything is executable in Windows).
- Don't use the owner and group arguments for tar on Windows.
- Hide the stderr output of which. In Windows it prints the full PATH in
case of failures, which is disrupting.
- Quote many paths in Windows in the output of build-script results.
- Provide a version of mock-distcc that can be executed in Windows. The
raw Python script cannot.
- Change the expected results for clang/clang++ to the right values in
Windows (clang-cl in both cases).
This hopefully provides an example for other people on how to do this sort of
thing.
The presets are called "stdlib_RDA,standalone{,[,]notest}". It requires one parameter:
toolchain_path which should be the bin directory of your toolchain. Example:
```
build-script --preset=stdlib_RDA,standalone toolchain_path=$MY_TOOLCHAIN/usr/bin
build-script --preset=stdlib_RDA,standalone,notest toolchain_path=$MY_TOOLCHAIN/usr/bin
```
The --dump-config option prints a recursive JSON dump of the BuildScriptInvocation object’s properties, which gives access to essentially all of the knowledge build-script has about the build before it starts performing it. This makes the output more flexible and extensible without severely convoluting the implementation, but doesn’t really give us a stable representation of that data.
If passed, build-script doesn’t build anything; it just prints the full path to the directory the invocation would have built its products in. This is intended to allow you to build tools which take build-script options like --debug and --xcode and use them to determine the build directory you’re currently using.
Build a separate compiler-rt instance for running the tests. It is built
and tested against an installed toolchain instead of the llvm-build-dir.
Install everything we need to run tests (CMake modules, FileCheck, etc.)
into the toolchain directory.
Add synthetic target 'all' for llvm-install-components. Also we must set
LLVM_INSTALL_UTILS=ON, so the utilities required by tests (e.g.,
FileCheck) are included in the install target.
