https://github.com/apple/swift-corelibs-xctest/pull/43 introduces
a dependency between XCTest and Foundation. Modify the build script
in order to properly build all products:
- Build Foundation before XCTest, then link Foundation when building
XCTest by using new '--foundation-build-dir' option.
- Link Foundation when testing SwiftPM by using new '--foundation'
option.
- On Linux, ensure Foundation is built when XCTest is.
Prior to https://github.com/apple/swift-corelibs-xctest/pull/57 and
https://github.com/apple/swift-corelibs-xctest/pull/58, the
swift-corelibs-xctest build script did not provide a way an already
built XCTest.so to be tested or installed. As a result, the Swift
build script would build XCTest several times.
For example, the following invocation would build XCTest three separate
times:
```
$ utils/build-script --xctest --test -- --install-xctest
```
Modifications to the XCTest build script now allow a prebuilt XCTest to
be tested (via the `build_script.py test` subcommmand) and installed
(via the `build_script.py install` subcommand). Use these in the Swift
build script to build XCTest only once, then test and install the built
version.
Also, explicitly disable XCTest installation on OS X. XCTest's
`build_script.py` only supports non-Darwin platforms, so running
`utils/build-script --xctest -- --install-xctest` on OS X used to cause
the build script to fail because of how that script invokes `swiftc`.
It now fails with an explicit error indicating `--install-xctest` is
unsupported.
I am going to use the link job for limiting swift lto compile time.
The reason not to use the same variables as LLVM (i.e. LLVM_PARALLEL_LINK_JOBS)
is that Swift since it is compiling more IR may have a larger memory
representation implying less parallel linking jobs than LLVM can be used on
bots.
http://public.kitware.com/pipermail/cmake-developers/2015-November/026993.html
We check for this in build-script-impl and if you are running such a version,
special flags are passed in to work around the issue. If you do not have this verison of cmake, this change should not affect you in any way.
This will be fixed in cmake 3.4.1.
- Migrate `SKIP_TEST_IOS`, `SKIP_TEST_TVOS`, and `SKIP_TEST_WATCHOS` to
Python.
- In the `build-script-impl` shellscript, only deal with
`SKIP_TEST_*_HOST` and `SKIP_TEST_*_SIMULATOR` variables.
- Introduce a `--host-test` flag to the Python `build-script` in order
to allow users to specify whether to run host tests. These flags
still don't do anything.
- Fix typo: `skip-build-tvos_device` was meant to be `skip-build-tvos-device`.
It's possible to cross-compile for iOS while skipping stdlib tests
on OS X:
```
$ utils/build-script --ios -- --skip-test-osx
```
The same is not possible on Linux. Add options to skip builds and
tests on non-Darwin platforms: Linux, FreeBSD, and Cygwin.
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.
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 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.
Three small changes for building libdispatch and foundation together.
(1) Put libdispatch into PRODUCTS before foundation
(2) Pass path to swift down into libdispatch build
(3) Pass paths to libdispatch down into foundation build
This brings down StdlibUnittest build time to 90 seconds with either
a DebugAssert or a ReleaseAssert compiler.
The new library, StdlibCollectionTests, is only built when running
validation tests.
