Allow swift-corelibs-xctest to be built and tested on Linux and OS X,
via `utils/build-script --xctest --test`.
On OS X, XCTest is built via `xcodebuild`, which has been possible since
https://github.com/apple/swift-corelibs-xctest/pull/47. It's tested via
the "SwiftXCTestFunctionalTests" Xcode target. Keep in mind that
`xcodebuild` must be configured on the host machine to use a Swift
toolchain that can build XCTest--as of
https://github.com/apple/swift-corelibs-xctest/pull/48, that would be
`swift-DEVELOPMENT-SNAPSHOT-2016-02-08` or later.
On Linux, XCTest is built and tested via the project's
`build_script.py`, which has been possible since
https://github.com/apple/swift-corelibs-xctest/pull/46.
This preset is meant for smoke testing of pull requests. It is an
attempt to make the mac os x smoke test (~140 min) closer in time to the
linux test (~15 minutes).
instead have a new preset buildbot_incremental_base_all_platforms that
has those flags.
The reason why this makes sense is:
1. There are a bunch of presets that inherit from
buildbot_incremental_base that do not want to build ios/tvos. So they
turn it off. That is wasteful and bug inducing.
2. I am going to be adding such a bot for OS X smoke tests. It only runs
OS X tests and builds OS X to keep the smoke test time down.
Before this commit:
```
$ flake8
./utils/rth:34:17: E127 continuation line over-indented for visual indent
./utils/rth:67:27: E127 continuation line over-indented for visual indent
$
```
After this commit:
```
$ flake8
$
```
- Since this file has a Python shebang (`#!/usr/bin/env python`) at the top, it can be invoked directly, without specifying which Python interpreter to use on the command line.
- Use the `%(prog)s` substitution instead of writing the program name again explicitly.
Rather than archiving symbols at the very end of the build-script-impl
shellscript, do so at the end of the Python build-script. A small step towards
achieving SR-237.
Rather than setting the path to the .xctoolchain in the build-script-impl
shellscript, do so in the Python build-script. A small step towards
achieving SR-237.
Rather than setting a default value for the INSTALL_PREFIX in the
build-script-impl shellscript, do so in the Python build-script. A small step
towards achieving SR-237.
Rather than printing `xcodebuild` version information in the
build-script-impl shellscript, do so in the Python build-script. A small step
towards achieving SR-237.
Rather than determining which builds to skip in the build-script-impl
shellscript, do so in the Python build-script. A small step towards
achieving SR-237.
Rather than determining whether to build Ninja in the build-script-impl
shellscript, do so in the Python build-script. A small step towards achieving
SR-237.
The omit-needless-words script has grown into a more general "API
dumping" script. Make it a bit more useful by installing it alongside
swift-ide-test, symlinking it in the build directory next to
swift-ide-test (for Swift developers), and defaulting to using the
swift-ide-test in the same directory as the script. Now it's fairly
easy to dump the API for a given SDK with, e.g.,
swift-api-dump.py -s iphoneos
When invoking omit-needless-words without a module argument (-m), the
script will now dump the API of all of the frameworks in the provided
SDKs. One can also specify multiple SDK arguments, e.g.,
omit-needless-words.py -s iphoneos macosx
to dump the APIs for the modules of multiple SDKs. The invocation
omit-needless-words.py -s macosx iphoneos watchos appletvos
will dump everything in one shot.
One can still dump individual modules with "-m", but you'll now have
to specify an SDK from which to retrieve the module.
The short-term goal here is to get everything compiling and all the tests
passing.
The mid-term goal is to test the performance of a resilient stdlib.
The long-term goal is to make this the default (and only) build mode.
This should be considered EXPERIMENTAL; we can't even build libSwiftCore
successfully yet.
