Fix the OS X XCTest CI preset:
1. Installation of XCTest isn't supported on OS X. After all, the
library is meant to be used on Linux, and not intended to be used or
installed on OS X. Therefore, no longer pass an `INSTALL_PATH` to the
`xcodebuild` invocation on OS X.
2. `xcodebuild` expects `swift-stdlib-tool` to be present in the same
directory as the `SWIFT_EXEC` it's given. Re-use some shellscript
from the toolchain installation script to copy the stdlib-tool
substitute.
This allows the XCTest CI to work on all platforms.
When enabling ASAN on LLVM it does not build the asan libraries, and this means
that we can't use it to sanitize swift. This change disables ASAN on the
internal clang but keeps it on the Swift project.
This commit makes the swift build scripts use the clang that we build as part of
the build process in order to build the Swift runtime, and not the host
compiler. This change is necessary for using new clang features immediately after they are introduced.
One example for such feature is new function calling conventions, or new c-level attributes.
We want to have the option of building the standard library without
-sil-serialize-all.
For now, the build crashes in the SIL verifier due to various issues;
upcoming patches will address these.
This is part of the larger goal of building the stdlib with
-enable-resilience.
Part of https://bugs.swift.org/browse/SR-267.
The XCTest CI is currently broken for OS X. Invoking `xcodebuild`, even
when setting the correct `SWIFT_EXEC`, was unable to build Foundation.
The problem was that a flag to link the Objective-C runtime was not being set
as it would be when building with a Swift toolchain.
Set the flag to get the builds passing. The XCTest CI presets should
pass on all platforms with this change.
Because the `xcodebuild` invocation used to compile swift-corelibs-xctest on OS X uses a toolchain that is usually out of date, it often fails (for example, when building the newly migrated Swift 3 code).
Pass the path to the freshly built `swiftc` to `xcodebuild` in order to use the latest Swift compiler.
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.
