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.
This eliminates the need for the swig binary to be present.
This was already the case for OS X, but required extra cmake
arguments for cmake LLDB builds.
This change adds a '-j' option to the top-level
build script. The computed defaults may not
always be suitable.
Tested by building for Ninja (default), Make (-m), and XCode (-x).
I also verified the jobs count via a process monitor.
This commit fixes two problems exposed by Makefile builds
(-m): (1) the cmark library directory is wrong and (2) the
COMMON_CMAKE_OPTIONS are not quoted when building swift (thus
"Unix Makefiles" ends up as two command line arguments).
Tested by building for Ninja (default), Make (-m), and XCode (-x).
