Most other parts of `build-script-impl` print the unknown argument when
a switch statement fails to pattern match. Do the same for unknown
arguments passed to `--cross-compile-tools-deployment-targets`.
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`.
Begins work on SR-237.
Rather than determining the number of jobs to use for `make` or
`dsymutil` from within build-script-impl, this change passed in those
values from above.
Furthermore, because we can determine the number of build jobs via a
builtin Python function, we figure out the number of jobs to use from
within `utils/build-script`. Now, by default, the same number of jobs
will be used to build this project as there are cores on the host
machine. Users may still specify a different number, as before, using
the `--jobs` option.
This introduces a behavioral change. Before, running
`utils/build-script` would run something like the following `cmake`
command:
```
cmake --build /build/Ninja-DebugAssert/llvm-macosx-x86_64 -- all
```
Notice the lack of jobs specified. The new default is something like
the following:
```
cmake --build /build/Ninja-DebugAssert/llvm-macosx-x86_64 -- -j8 all
```
Notice that the number of jobs is exlicitly passed to the command.
CMake supports generation of compilation databases. These have many uses, not
least of which is in supporting code-completion engines like
https://github.com/Valloric/YouCompleteMe.
Add the `--export-compile-commands` flag to `utils/build-script`.
Setting this flag passes `-DCMAKE_EXPORT_COMPILE_COMMANDS=ON` to CMake,
which results in a `compile_commands.json` file being generated along
with built products like `cmark`, `llvm`, and `swift`.
Currently prints 'Running Swift tests for:...' even if the skip-test-swift argument is set. Should only print this line if there are tests in the SWIFT_TEST_TARGETS array and they will not be skipped.
In the case some SKIP_TEST_* flag is set, and test_this_target is False for all targets, then SWIFT_TEST_TARGETS will be an empty array. Avoid printing 'Running Swift tests...' with an empty array.
