Refactor Commands module
#5807
Merged
Refactor Commands module
#5807
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
very cool! |
neonichu
force-pushed
the
swift-bootstrap-cmd
branch
from
6d2c99f to
14c4329
Compare
|
@swift-ci please smoke test |
|
swiftlang/sourcekit-lsp#650 |
|
swiftlang/swift#61574 |
|
Bootstrapping SwiftPM on Windows with "debug" configuration is possible, but in release build it will hit swiftlang/swift-llbuild#844, so this is currently unusable. It’s nice to see SwiftPM being bootstrapped on Windows, in align with other platforms. |
|
swiftlang/swift#61574 |
|
Looks like this is an unrelated issue on the CI right now? I also saw it on TSC PRs. |
|
swiftlang/swift#61574 |
neonichu
added a commit
that referenced
this pull request
Oct 27, 2022
This is an initial step of unwinding the direct dependency of individual commands to a concrete build system implementation, through two major changes: - Adding a new target `DriverSupport` which contains integration with swift-driver that is independent of a concrete build system being used (today mostly `checkSupportedFrontendFlags(flags:fileSystem)` but there could be more in the future) - Adding a new `BuildSystemProvider` API which handles instantiation of a concrete build system. This will e.g. allow creating a `SwiftCommand` which doesn't depend on the `XCBuildSupport` module (which is going to help with #5807) and also provides a way to generally clean up (almost) all callsites from directly interacting with a concrete build system.
|
Split out #5846 to address the concerns about build system support. |
neonichu
added a commit
that referenced
this pull request
Oct 27, 2022
This is an initial step of unwinding the direct dependency of individual commands to a concrete build system implementation, through two major changes: - Adding a new target `DriverSupport` which contains integration with swift-driver that is independent of a concrete build system being used (today mostly `checkSupportedFrontendFlags(flags:fileSystem)` but there could be more in the future) - Adding a new `BuildSystemProvider` API which handles instantiation of a concrete build system. This will e.g. allow creating a `SwiftCommand` which doesn't depend on the `XCBuildSupport` module (which is going to help with #5807) and also provides a way to generally clean up (almost) all callsites from directly interacting with a concrete build system.
neonichu
added a commit
that referenced
this pull request
Oct 27, 2022
This is an initial step of unwinding the direct dependency of individual commands to a concrete build system implementation, through two major changes: - Adding a new target `DriverSupport` which contains integration with swift-driver that is independent of a concrete build system being used (today mostly `checkSupportedFrontendFlags(flags:fileSystem)` but there could be more in the future) - Adding a new `BuildSystemProvider` API which handles instantiation of a concrete build system. This will e.g. allow creating a `SwiftCommand` which doesn't depend on the `XCBuildSupport` module (which is going to help with #5807) and also provides a way to generally clean up (almost) all callsites from directly interacting with a concrete build system.
neonichu
added a commit
that referenced
this pull request
Oct 27, 2022
This is an initial step of unwinding the direct dependency of individual commands to a concrete build system implementation, through two major changes: - Adding a new target `DriverSupport` which contains integration with swift-driver that is independent of a concrete build system being used (today mostly `checkSupportedFrontendFlags(flags:fileSystem)` but there could be more in the future) - Adding a new `BuildSystemProvider` API which handles instantiation of a concrete build system. This will e.g. allow creating a `SwiftCommand` which doesn't depend on the `XCBuildSupport` module (which is going to help with #5807) and also provides a way to generally clean up (almost) all callsites from directly interacting with a concrete build system.
neonichu
added a commit
that referenced
this pull request
Oct 27, 2022
This is an initial step of unwinding the direct dependency of individual commands to a concrete build system implementation, through two major changes: - Adding a new target `DriverSupport` which contains integration with swift-driver that is independent of a concrete build system being used (today mostly `checkSupportedFrontendFlags(flags:fileSystem)` but there could be more in the future) - Adding a new `BuildSystemProvider` API which handles instantiation of a concrete build system. This will e.g. allow creating a `SwiftCommand` which doesn't depend on the `XCBuildSupport` module (which is going to help with #5807) and also provides a way to generally clean up (almost) all callsites from directly interacting with a concrete build system.
neonichu
force-pushed
the
swift-bootstrap-cmd
branch
from
14c4329 to
73137a8
Compare
neonichu
changed the title
Commands module
|
Simplified this PR a little bit for easier review and updated it based on the refactoring I have done separately. Once this lands, there will be two eventual follow-up PRs:
|
|
@swift-ci please smoke test |
neonichu
force-pushed
the
swift-bootstrap-cmd
branch
from
73137a8 to
20b354a
Compare
|
@swift-ci please smoke test |
tomerd
reviewed
Nov 1, 2022
tomerd
reviewed
Nov 1, 2022
tomerd
reviewed
Nov 1, 2022
tomerd
reviewed
Nov 1, 2022
| observabilityScope: customObservabilityScope ?? swiftTool.observabilityScope | ||
| ) | ||
| }, | ||
| ], uniquingKeysWith: { a, b in |
There was a problem hiding this comment.
this is a bit unclear to me, we are merging a map of 1?
There was a problem hiding this comment.
We're merging with the providers from defaultBuildSystemProvider above, right now this doesn't have an effect, but I wanted to keep it forward compatible.
tomerd
reviewed
Nov 1, 2022
This is the initial step in reducing the first stage of the bootstrap build. Currently, the initial bootstrap build using CMake is essentially building the entirety of SwiftPM and that is (mostly) because the `Commands` module pulls in everything that SwiftPM possibly offers. This introduces a new `CoreCommands` module which contains the necessary parts for providing a minimal build command using the native build system. This can be used to provide a new `swift-bootstrap` executable which is a minimal version of `swift-build`, but actually doing so will be a separate PR. The Windows build currently relies entirely on CMake, so initally we will not be able to profit much from the minimal build, but this will get us closer to doing so in the future.
neonichu
force-pushed
the
swift-bootstrap-cmd
branch
from
20b354a to
fab38b1
Compare
|
@swift-ci please smoke test |
CodaFi
added a commit
that referenced
this pull request
Nov 2, 2022
This was removed in #5807 before projects had time to migrate. Restore this option until they do.
CodaFi
added a commit
that referenced
this pull request
Nov 2, 2022
This was removed in #5807 before projects had time to migrate. Restore this option until they do. rdar://101841334
Closed
CodaFi
added a commit
that referenced
this pull request
Nov 2, 2022
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is the initial step in reducing the first stage of the bootstrap build. Currently, the initial bootstrap build using CMake is essentially building the entirety of SwiftPM and that is (mostly) because the
Commandsmodule pulls in everything that SwiftPM possibly offers.This introduces a new
CoreCommandsmodule which contains the necessary parts for providing a minimal build command using the native build system. This can be used to provide a newswift-bootstrapexecutable which is a minimal version ofswift-build, but actually doing so will be a separate PR.The Windows build currently relies entirely on CMake, so initally we will not be able to profit much from the minimal build, but this will get us closer to doing so in the future.