Refactor build system support #5846
Merged
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
|
@swift-ci please smoke test |
neonichu
commented
Oct 27, 2022
neonichu
commented
Oct 27, 2022
|
@swift-ci please smoke test macOS |
tomerd
reviewed
Oct 27, 2022
tomerd
reviewed
Oct 27, 2022
tomerd
reviewed
Oct 27, 2022
tomerd
reviewed
Oct 27, 2022
tomerd
reviewed
Oct 27, 2022
tomerd
reviewed
Oct 27, 2022
tomerd
reviewed
Oct 27, 2022
tomerd
reviewed
Oct 27, 2022
tomerd
reviewed
Oct 27, 2022
|
Looks like there's an issue to be addressed with the CMake build, probably a missing dependency: |
|
Cannot repro the CMake issue in a local build 🤔 |
Ah, that's because I was on the wrong branch 🤣 |
|
@swift-ci please smoke test |
neonichu
force-pushed
the
refactor-build-system-support
branch
from
81d3ac5 to
6fa8141
Compare
|
@swift-ci please smoke test |
neonichu
force-pushed
the
refactor-build-system-support
branch
from
6fa8141 to
10af1c1
Compare
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
refactor-build-system-support
branch
from
10af1c1 to
151804b
Compare
|
@swift-ci please smoke test |
|
@swift-ci please smoke test macOS |
tomerd
approved these changes
Oct 27, 2022
neonichu
added a commit
that referenced
this pull request
Oct 31, 2022
This was broken in #5846 which accidentally used the default value instead of passing along the global option. rdar://101681661
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 an initial step of unwinding the direct dependency of individual commands to a concrete build system implementation, through two major changes:
DriverSupportwhich contains integration with swift-driver that is independent of a concrete build system being used (today mostlycheckSupportedFrontendFlags(flags:fileSystem)but there could be more in the future)BuildSystemProviderAPI which handles instantiation of a concrete build system. This will e.g. allow creating aSwiftCommandwhich doesn't depend on theXCBuildSupportmodule (which is going to help with RefactorCommandsmodule #5807) and also provides a way to generally clean up (almost) all callsites from directly interacting with a concrete build system.