[2/2][build_script.py] Add "install" subcommand #58
Conversation
modocache
force-pushed
the
build-script-subcommands-install
branch
from
2ab127e to
f636591
Compare
|
@swift-ci please test |
This builds upon the subcommand system added in swiftlang#57, to add an install command. As that pull request describes, because there is no way to test or install XCTest without also building the project, the current Swift build script ends up building XCTest three times. This adds an "install" subcommand that allows an already built XCTest to be installed.
modocache
force-pushed
the
build-script-subcommands-install
branch
from
f636591 to
9502b80
Compare
|
@mike-ferris-apple Could you ask @swift-ci to please test? Once this is merged, I can change the Swift build script to only build XCTest as many times as necessary. |
|
@swift-ci please test |
|
It looks like the CI hook here isn't going through, since the last build on this job is from Feb. 29. Perhaps @shahmishal can help debug? @modocache I quite like the flexibility you're introducing with this series of build script improvements. 👍 |
|
Thanks, @briancroom! But, yeah, I'm worried the CI must have become sentient, and is disobeying direct orders!! 🚨 Seriously, though, I think there's some work being done to enable the CI for external core members. Maybe it's a bit unresponsive in the interim, even for @mike-ferris-apple... |
| @@ -26,6 +26,14 @@ def run(command): | |||
| subprocess.check_call(command, shell=True) | |||
|
|
|||
|
|
|||
| def _mkdirp(path): | |||
There was a problem hiding this comment.
I'm curious about this _ and the ones on _build etc. Is this a Python convention I should be familiar with for internal (/non-exported?) functions? If that's the case, how is this function different from e.g. note in its role in the module?
There was a problem hiding this comment.
I do think preceding with an underscore is typically done for "internal" functions, but I may be wrong. note was tangential to this change so I left it alone. @practicalswift, what do you think?
There was a problem hiding this comment.
It is admittedly kind of silly, since this is just a single script, so really every function is "internal" 😛
|
@swift-ci Please test |
|
@swift-ci Please test OS X platform |
|
Amazing! Thanks for the OS X support, @shahmishal! It looks like the build is failing because This pull request only affects Linux, and the tests are passing on that platform, so I'll go ahead and merge this. |
[2/2][build_script.py] Add "install" subcommand
Prior to swiftlang/swift-corelibs-xctest#57 and swiftlang/swift-corelibs-xctest#58, the swift-corelibs-xctest build script did not provide a way an already built XCTest.so to be tested or installed. As a result, the Swift build script would build XCTest several times. For example, the following invocation would build XCTest three separate times: ``` $ utils/build-script --xctest --test -- --install-xctest ``` Modifications to the XCTest build script now allow a prebuilt XCTest to be tested (via the `build_script.py test` subcommmand) and installed (via the `build_script.py install` subcommand). Use these in the Swift build script to build XCTest only once, then test and install the built version. Also, explicitly disable XCTest installation on OS X. XCTest's `build_script.py` only supports non-Darwin platforms, so running `utils/build-script --xctest -- --install-xctest` on OS X used to cause the build script to fail because of how that script invokes `swiftc`. It now fails with an explicit error indicating `--install-xctest` is unsupported.
This builds upon the subcommand system added in #57, to add an install command. That pull request should be reviewed and merged prior to this one.
As that pull request describes, because there is no way to test or install XCTest without also building the project, the current Swift build script ends up building XCTest three times. This adds an "install" subcommand that allows an already built XCTest to be installed.