I have been doing this using extra-cmake-args/etc... just feels better to have
an actual option to do this.
Just did this quickly while waiting for my Linux build to finish that uses
extra-cmake-args to set the linker.
This was quite brittle and has now been superseded
by swift-xcodegen. Remove the CMake/build-script
logic for it, leaving the option behind to inform
users to switch to using xcodegen instead.
This is the start of the removal of the C++ implementation of libSyntax
in favor of the new Swift Parser and Swift Syntax libraries. Now that
the Swift Parser has switched the SwiftSyntaxParser library over to
being a thin wrapper around the Swift Parser, there is no longer any
reason we need to retain any libSyntax infrastructure in the swift
compiler.
As a first step, delete the infrastructure that builds
lib_InternalSwiftSyntaxParser and convert any scripts that mention
it to instead mention the static mirror libraries. The --swiftsyntax
build-script flag has been retained and will now just execute the
SwiftSyntax and Swift Parser builds with the just-built tools.
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.
The library `six` provides compatibility between Python 2, and 3. It's no
longer necessary once we migrate of Python 2 completely.
Also remove any custom logic for Python 2 (the ones referenced by
a commentanyways).
https://bugs.swift.org/browse/SR-16025
SwiftVersionType needs 5 components, and ClangVersionType needs to match
SwiftVersionType because some build automation wants to mark the clang
version as being the same as the Swift version while generating version
numbers.
Fixes rdar://85508050
This will make sure that compiler developers are using the new driver when they build the compiler locally and use it.
- Adds a new build-script product category: before_build_script_impl for products we wish to build before the impl products.
- Adds a new EarlySwiftDriver product to that category, which gets built with the host toolchain.
- Adds an escape hatch: --skip-early-swift-driver
- Adjusts the swift CMake configuration with an additional step: swift_create_early_driver_symlinks which (if one was built) creates symlinks in the swift build bin directory to the EarlySwiftDriver swift-driver and swift-help executables.
- Adds a new test subset : only_early_swiftdriver, which will get built into a corresponding CMake test target: check-swift-only_early_swiftdriver-* which runs a small subset of driver-related tests against the Early SwiftDriver.
- This subset is run always when the compiler itself is tested (--test is specified)
- With an escape disable-switch: --skip-test-early-swift-driver
- All tests outside of only_early_swiftdriver are forced to run using the legacy C++ driver (to ensure it gets tested, still).
NOTE: SwiftDriver product (no 'Early') is still the main product used to build the driver for toolchain installation into and for executing the product's own tests. This change does not affect that.
The `mock.assert_called()` method was added in Python 3.6,
so fails on some of our older CI machines that use Python 3.5.
`assert(mock.called)` is precisely equivalent and works with
older versions of the Python unittest.mock library.
* More Python3 lint fixes
Some of the issues addressed include:
* Don't use `l` as a variable name (confusable with `1` or `I`)
* `print` statement does not exist in Py3, use `print` function instead
* Implicit tuple deconstruction in function args is no longer supported,
use explicit splat `*` at the call site instead
* `xrange` does not exist in Py3, use `range` instead
* Better name per review feedback
This causes build-script to use the conservative dependency information that I
committed. When one uses this option, it is assumed that one wants to also
install all built products.
Some notes:
1. I included an extra --install-all option so without --infer enabled
one can enable this sort of install everything that we want to
build behavior.
2. I added %cmake as a lit variable. I did this so I could specify in
my build-system unit tests that on Linux they should use the just
built cmake (if we built cmake due to an old cmake being on the
system). Otherwise, the build system unit tests took way too
long. These are meant to be dry-runs, so building this cmake again
is just wasteful and doesn't make sense.
3. I unified how we handle cmark, llvm, swift with the rest of the
build products by making them conditional on build_* variables, but
to preserve current behavior I made it so that they are just
enabled by default unlike things like
llbuild/swiftpm/foundation/etc. This was necessary since previously
we would just pass these flags to build-script-impl and
build-script didn't know about them. Now I taught build-script
about them so I can manipulate these skip-build-{cmark,llvm,swift}
and then just pass them down to build-script-impl if appropriate
rather than relying on build-script-impl to control if these are
built.
Once this lands, I think we are at a good enough place with
build-script until we get rid of build-script-impl in terms of high
value QoI that will imnprove productivity. Once build-script-impl is
destroyed, we can start paring back what build-script itself does.
This option configures the build directories without building any
targets. Splitting configuration from build allows for the decoupling
of build products. This decoupling is essential for the enlightened
way of developing Swift where the build-script is never actually used
to build anything, and build products can be independently
configured. When fully supported, this avoids many unnecessary
full/clean rebuilds and enables debugging by mixing-and-matching
configurations and rebuilding only select products after a change.
Sadly, the option has degraded, and a recent commit rendered it fully broken:
commit 34848e6026
Author: Alex Langford <apl@fb.com>
Date: Wed Jan 22 19:27:44 2020
[build] Unify logic to skip building projects in build-script-impl
The breaking commit was itself a reasonable cleanup. The underlying
problem was the original --skip-build was implemented using hacks that
conflated configuration with build.
This fix reinstates a reasonable situation:
--skip-build has no effect on configuration, as documented. It merely
skips building the targets. This is how it must behave to work as
intended.
--skip-build-{product} and its inverse --build-{product} controls
which products will be configured. These options are in heavy use
throughout the scripts, so changing the name (e.g. to --skip-config)
would be disruptive and of questionable benefit.
None of this changes the fact that any required build logic that
people have dumped into build-script-impl still effectively breaks the
enlightened way of building Swift, particularly when building
toolchain components.
This new module uses the build_swift.shell.ExecutableWrapper API to create a wrapper class around 'xcrun'. The wrapper class is instantiated and exposed under the name build_swift.wrappers.xcrun.
Having the test directory match the module we are testing means we can have scripts in the top level of utils/build_swift which can also have tests. As part of this re-structure the test utilties have been simplified somewhat and all tests no longer use a custom TestCase, rather the standard one exposed by the unittest module.
