build-script-impl now takes a --lldb-test-cc flag:
* when not specified, it will default to using the
just-built clang (i.e. in tree with swift) to
build the C/C++ test suite test inferior programs.
* when specified and equal to "host-toolchain", the
test suite test inferiors will be built with
the same compiler chosen as --host-cc.
* when set to anything else, it is assumed to be the
full path to a C compiler to use for compiling
LLDB test suite test inferiors.
Note the LLDB test suite only takes the C compiler and
derives the C++ compiler from the C compiler path. There
is no need to specify the C++ compiler directly.
Addresses the following issue:
https://bugs.swift.org/browse/SR-1207
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`.
