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.
`build-script-impl` currently maintains a list of
`NATIVE_TOOLS_DEPLOYMENT_TARGETS` -- host machine targets, for which
the resulting binaries can be run on the current machine.
However, there is only ever *one* host machine. This commit:
- Changes the `NATIVE_TOOLS_DEPLOYMENT_TARGETS` list parameter into a
single string parameter, `HOST_TARGET`.
- Promotes the logic to detect the host target to Python, and places it
in the `swift_build_support` module.
- Removes the hard-coded "macosx_x86_64" path to the LLVM and Clang
TableGen -- thereby unblocking future work to make cross-compilation
possible on platforms other than OS X.
- Also promotes cross-compilation target validation to Python, placing
it in the `swift_build_support` module.
Extend build-script, build-script-impl, and update-checkout
to include libdispatch. For now, libdispatch is not
built by default (user must enable via command line
argument).
Integration of testing is functional, but should be improved
in a later pull request. The basic autotools based test
harness does not give the nice high-level progress output
as the rest of the test suite.
A related pull request to libdispatch (#34) has some fixes
to the autotools build that are needed to enable the test
target to succeed when run in an external directory.
