In the past if one wanted to be able to develop using multiple swift repos, one
was often stymied by build-script always using build-script-impl from the swift
directory. This includes the case where one invokes the build-script from a
hypothetical directory called swift-2.
On Darwin platforms, the Swift build scripts generally use "xcrun" to
locate various tools, and the build-script's darwin-xcrun-toolchain option
is specified to xcrun. However, with the change to use the just-built clang
to build the runtime (PR #6112), there was an issue with the linker. Clang
normally tries to run the linker from the same directory as the clang
binary, but when there isn't one, it falls back on /usr/bin/ld, which is
just an xcrun-like wrapper. Since there is no way to specify an explicit
toolchain option in that case, set TOOLCHAINS in the environment to
make it use the linker from the specified toolchain.
rdar://problem/30709330
Fix the mocked output files of swiftc. Change the lookup of
clang from build-script to build-script-impl like all the other
commands. Pass more args to LLVM. Fix swiftenv creation. Fix unit tests.
The reason this patch works is that build-script-impl gets
all the arguments that are not handled by build-script.
* Add --ios-all etc with a helpful error
message for those who think it exists.
* Reject --ios --host-test early to avoid a cryptic
"build target does not exist" error much later.
build-script-impl assumes ICU is located at
```
LIBICU_SOURCE_DIR="${WORKSPACE}/icu"
```
However, build-script would try to set it to
```
<path-to-workspace>/libicu"
```
This is wrong, so fix it
Some cmark CMake stuff changed recently and the default rules
we have in the Python build script code doesn't behave correctly
anymore, likely because it was relying on incorrect settings.
Now, by default, if the cmark build type isn't specified, it will
follow Swift's. If we don't do this, Xcode builds are broken, and
building with Xcode is important.
This should help speed up people trying to compile the standard library and do
SILGen work. *NOTE* This will not necessarily result in a type checker that is
as fast as a release build since most likely the type checker will use some
link_once odr functions that are debug. But it should still be significantly
faster otherwise.
This makes getting to SILGen take 16 seconds on my machine instead of forever
when compiling with everything else in the compiler in debug mode.
Adds a three second delay when the `-c` or `--clean` options are
given to utils/build-script, providing a chance to cancel the build
before the existing build folder is removed.
This continues the workaround from 7213a4d8. We should still get a better
solution that does not hardcode the LLVM version like this. That is
tracked by rdar://problem/28801735
- <rdar://problem/27791475>
SwiftPM can now be built in release mode because all the outstanding
issues preventing that has been resolved. The major issues were:
* Building (and running) unit tests with @testable import in
* release. (swiftpm PR #758)
* Linker errors when building unit tests with wmo on linux. (SR-3034)
There is no reason not to do this (and it is really cheap) and I want to make
some scripts use it with various clang tooling techniques like clang-tidy to
improve code quality. This will ensure that by default people can just use these
scripts without knowing about how things are working under the hood.
