Rather than manually checking whether a code coverage argument was passed
to the build scipt, use `argparse` to set a default value. This results
in fewer lines of code.
Fixes:
* blank line at end of file
* closing bracket does not match indentation of opening bracket's line
* continuation line over-indented for hanging indent
* continuation line over-indented for visual indent
* continuation line unaligned for hanging indent
* inline comment should start with '# '
* missing whitespace around arithmetic operator
* missing whitespace around bitwise or shift operator
* multiple imports on one line
* multiple spaces after ':'
* multiple spaces after operator
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`.
Running the Python style guide checker
[`pep8`](https://pypi.python.org/pypi/pep8) on the Python code headers
in this repository results in the following error being emitted:
$ pep8 utils/build-script
utils/build-script:1:1: E265 block comment should start with '# '
utils/build-script:3:1: E266 too many leading '#' for block comment
utils/build-script:5:1: E266 too many leading '#' for block comment
utils/build-script:6:1: E266 too many leading '#' for block comment
utils/build-script:8:1: E266 too many leading '#' for block comment
utils/build-script:9:1: E266 too many leading '#' for block comment
utils/build-script:11:1: E265 block comment should start with '# '
utils/build-script:11:80: E501 line too long (80 > 79 characters)
The problem is that the code header used in most Python files in the
repository:
1. Do not place a space in between `#` and the rest of the comment.
2. Contains some lines that just barely exceed the recommend length
limit.
In addition, not all code headers in the repository follow the same
template.
This commit moves all Python code headers to the following template:
# subfolder/file_name.py - Very brief description -*- python -*--
#
# This source file is part of the Swift.org open source project
#
# Copyright (c) 2014 - 2015 Apple Inc. and the Swift project authors
# Licensed under Apache License v2.0 with Runtime Library Exception
#
# See http://swift.org/LICENSE.txt for license information
# See http://swift.org/CONTRIBUTORS.txt for the list of Swift project authors
#
# -----------------------------------------------------------------------------
#
# This file contains stuff that I am describing here in the header and will
# be sure to keep up to date.
#
# ----------------------------------------------------------------------------
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`.
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 reverts commit b08610bc3e.
The check for LLDB build variant really needs to happen in
build-script-impl. build-script can still take options after
the '--' separator that may control the final determination
of the LLDB build variant. These weren't all being considered
by the logic in build-script.
The configuration script for Foundation respects debug and release builds so a new option for foundation-build-type has been added to control the build variant of Foundation.
Resolve the FIXME for adding a mechanism for a custom invocation of running the Foundation unit tests
Foundation now has an install target provided from the generated ninja script such that the potentially error prone install script is dramatically simplified into a single encapsulation of a ninja phony target of "install"; so adopt this new target for installation
