Recursive lipo handles a mix of directories where some subdirectories
build only a single slice for the host and other subdirectories build
universal binaries (e.g., for a target). The former are lipo'd
together, while the latter were copied verbatim.
The `--copy-subdirs` option indicated that an entire subtree should be
copied verbatim, and this was applied to `lib/swift` to cover all of
the target libraries, with single-file exceptions provided by
`--explicit-src-files`. However, this doesn't account for host content
under `lib/swift` that needs to be lipo'd, i.e., the newly-introduced
shared libraries in `lib/swift/host` that are part of host tools.
Revise the semantics of `--copy-subdirs`. Instead of copying the entire
directory verbatim, perform the normal recursion into these
subdirectories. When there are executable files that aren't identical,
check whether they have overlapping architectures: if they don't, lipo
them. If they do, and we're in a "copied" subdirectory, take one of
the files because they're considered equivalent. This gives a more
fine-grained semantics to `--copy-subdirs` that allows us to both lipo
executables/shared libraries and also construct Swift modules.
The `__future__` we relied on is now, where the 3 specific things are
all included [since Python 3.0](https://docs.python.org/3/library/__future__.html):
* absolute_import
* print_function
* unicode_literals
* division
These import statements are no-ops and are no longer necessary.
This library is contained in `lib/swift/<OS>/`, which `recursive-lipo` assumes contains the stdlib, and other Swift code built fat from the get-go. `libSwiftScan` is a part of the compiler build, and is therefore built for the host in a given build, which means toolchain installation requries that we use `lipo` to produce a fat shared library for it.
Resolves rdar://74490218
* 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
The repo contains roughly 80 Python scripts. "snake_case" naming is used for
local variables in all those scripts. This is the form recommended by the PEP 8
naming recommendations (Python Software Foundation) and typically associated
with idiomatic Python code.
However, in nine of the 80 scripts there were at least one instance of
"camelCase" naming prior to this commit.
This commit improves consistency in the Python code base by making sure that
these nine remaining files follow the variable naming convention used for
Python code in the project.
References:
* PEP 8: https://www.python.org/dev/peps/pep-0008/
* pep8-naming: https://pypi.python.org/pypi/pep8-naming
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)
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
In Python 3, 'print' was changed from a statement to a function. Using
the __future__ module allows scripts to use print function whether
running with Python 2.6+ or Python 3.x. This commit changes as many
instances of print as I could find to use the print function and the
__future__ module.
This adds support to build-script and cmake scripts for cross-compiling the host tools in addition to stdlib.
To cross-compile, build-script-impl now accepts --cross-compile-tools-deployment-targets with a space separated list of targets to cross compile host Swift tools for.
For example: $ build-script ...other-args... -- --cross-compile-tools-deployment-targets="iphoneos-arm64 iphoneos-armv7".
When installing cross-compiled tools, it now also merges and runs lipo to produce fat binaries by merging the cross-compiled target architectures.
Swift SVN r24712
