* 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
https://github.com/apple/swift-corelibs-xctest/pull/43 introduces
a dependency between XCTest and Foundation. Modify the build script
in order to properly build all products:
- Build Foundation before XCTest, then link Foundation when building
XCTest by using new '--foundation-build-dir' option.
- Link Foundation when testing SwiftPM by using new '--foundation'
option.
- On Linux, ensure Foundation is built when XCTest is.
- Migrate `SKIP_TEST_IOS`, `SKIP_TEST_TVOS`, and `SKIP_TEST_WATCHOS` to
Python.
- In the `build-script-impl` shellscript, only deal with
`SKIP_TEST_*_HOST` and `SKIP_TEST_*_SIMULATOR` variables.
- Introduce a `--host-test` flag to the Python `build-script` in order
to allow users to specify whether to run host tests. These flags
still don't do anything.
- Fix typo: `skip-build-tvos_device` was meant to be `skip-build-tvos-device`.
It's possible to cross-compile for iOS while skipping stdlib tests
on OS X:
```
$ utils/build-script --ios -- --skip-test-osx
```
The same is not possible on Linux. Add options to skip builds and
tests on non-Darwin platforms: Linux, FreeBSD, and Cygwin.
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 setting the path to the .xctoolchain in the build-script-impl
shellscript, do so in the Python build-script. A small step towards
achieving SR-237.
Rather than setting a default value for the INSTALL_PREFIX in the
build-script-impl shellscript, do so in 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.
Rather than determining which builds to skip in the build-script-impl
shellscript, do so in the Python build-script. A small step towards
achieving SR-237.
Rather than determining whether to build Ninja 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.
Fixes:
* multiple statements on one line (colon) (E701)
* missing whitespace around arithmetic operator (E226)
* missing whitespace around operator (E225)
* closing bracket does not match visual indentation (E124)
* blank line contains whitespace (W293)
* continuation line missing indentation or outdented (E122)
* continuation line over-indented for hanging indent (E126)
* missing expected blank line (E301)
* trailing whitespace (W291)
* unexpected spaces around keyword / parameter equals (E251)
* whitespace after '(', '[' or '{' (E201)
* whitespace before ')', ']' or '}' (E202)
* whitespace before ',' or ':' (E203)
Extend build-script, build-script-impl, and update-checkout
to include libdispatch. For now, libdispatch is not
built by default (user must enable via command line
argument).
Integration of testing is functional, but should be improved
in a later pull request. The basic autotools based test
harness does not give the nice high-level progress output
as the rest of the test suite.
A related pull request to libdispatch (#34) has some fixes
to the autotools build that are needed to enable the test
target to succeed when run in an external directory.
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.
