If -n or --dry-run is specified in command line arguments, print the commands
that would be executed to stdout, but do not execute them.
Supported in build-script and build-toolchain.
utils/build-script -n -Rt
utils/build-script -n --preset=buildbot_incremental,tools=RA,stdlib=RA
utils/build-toolchain -n local.swift
- Use consistent terminology for target platforms, disambiguate uses of
'deployment_target' in to 'host' and 'stdlib_targets'
- Changed parameters to build script:
- install-prefix no longer has to include toolchain-prefix on OSX
- swift-sdks has been replaced by stdlib-deployment-targets
- built-stdlib-deployment-targets lets you restrict which of the
stdlib-deployment targets are built
- Calculate stdlib_targets per host, to facilitate future cross-compiling
- Only use executables from LOCAL_HOST
- Only execute testable targets of the LOCAL_HOST
- Remove some cases of switching on 'uname' to facilitate future
cross-compiling
- This should fix possible issues with the test outputs being in a shared
directory on CI machines running concurrent builds.
- https://bugs.swift.org/browse/SR-1628
When we are building LLVM create symlinks to the c++ headers. We need to do this
before building LLVM since compiler-rt depends on being built with the just
built clang compiler. These are normally put into place during the cmake step of
LLVM's build when libcxx is in tree... but we are not building llvm with libcxx
in tree when we build swift. So we need to do cmake's work here.
rdar://26284108
It seems that distcc --randomize is causing cmake to invoke configuration
commands on remote machines. This is slow. Instead, just use the localhost host
when running cmake.
The rest of the build is distributed as normal.
A script checks if the output object file is written only once even if the compiler is invoked multiple times.
The main purpose of this check is to ensure that the compiler is deterministic (until IRGen).
Otherwise, we run into an issue with certain clangs and linking in libc++. libc++
in certain clangs require a minimum deployment target of at least 10.7.
I have not investigated further since I am trying to make progress on the
branching scheme.
rdar://26081474
(cherry picked from commit 2a27443f3ee63cc55e952e4cfb43c24661c4b7ca)
Adapt build-script-impl LLDB test suite runner launch code
for the LLDB package name changes that occurred upstream.
(cherry picked from commit b139e655b5)
This not only is the more canonical way to enable lto in LLVM but in addition
without this change, the swift compiler unittests will not build with LTO
resulting in funky LTO errors like rdar://25968091.
rdar://24717107
- llbuild builds before Swift, so we can't use the Swift compiler we are in the
process of building for it. For now, just disable the bindings entirely.
This will be a problem if SwiftPM ever decides that it wants to use the Swift
bindings to manage builds more effectively.
- Get it to work as `build-script` arguments.
- Fixed quoting problem
- Replaced --user-config-args: Error for --user-config-args.
- Moved to the position where it can override any options
