- This improves the error messages when commands fail (or don't exist) to show
a one-line summary of the issue instead of the Python backtrace, and matches
what was being done by the matching function in `SwiftBuildSupport`.
Before, we have to explicitly specify migrated args:
migrate_impl_args(argv, [... migrated arg list ...])
This change makes all *unknown* arguments to be automatically forwarded to
'build-script-impl'.
Not all machines may have all platforms' SDKs installed.
xcodebuild already has a command to print the versions of all
SDKs installed. For convenience, also provide a function that
returns the identifiers for all installed SDKs.
rdar://problem/25618455
* E101: indentation contains mixed spaces and tabs
* E111: indentation is not a multiple of four
* E128: continuation line under-indented for visual indent
* E302: expected 2 blank lines, found 1
* W191: indentation contains tabs
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 printing `xcodebuild` version information in the
build-script-impl shellscript, do so in the Python build-script. A small step
towards achieving SR-237.
`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.
SR-237 calls for `build-script` and `build-script-impl` to be merged. This
commit takes another step towards that goal by moving the logic that finds
the path to the CMake executable up into `build-script`.
Users of `build-script` were previously able to specify which CMake
they wished to use via `build-script-impl` args, like so:
```
$ utils/build-script -- --cmake=/foo/bar/cmake
```
This commit preserves that behavior, while also allowing users to
specify that path via `build-script` args:
```
$ utils/build-script --cmake=/baz/cmake -- --other --flags
```
https://bugs.swift.org/browse/SR-237 calls for `build-script` and
`build-script-impl` to be merged. This commit takes another step towards
that goal by moving the logic that finds the path to the `clang` and
`clang++` executables up into Python-land.
Rather than simply moving all of the logic into `utils/build-script`,
this commit moves relevant functions into a new Python module, named
`swift_build_support`. This has several benefits:
- The logic can be tested. Whereas `build-script-impl` needed to be run
in order to verify its behavior, the logic extracted out of it into
`swift_build_support` can be tested in isolation.
- The logic can be split up into several files without polluting the
`utils` directory, which now contains many different files that are
unrelated to `build-script`.
