[Build/PackageGraph] Sink fallback logic for macro/plugin/test products and packages identification into ModulesGraph
#7646
Conversation
This file contains 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
…ts and packages identification into `ModulesGraph` This is a temporary fix until we can figure out a proper way to handle situations were all we get is a name of a product or a target. Resolves: rdar://129400066
xedin
requested review from
bnbarham,
MaxDesiatov,
jakepetroules and
francescomikulis
as code owners
|
@swift-ci please test |
xedin
commented
Jun 7, 2024
| // a macro, plugin, or a test. Ideally we'd ask a build system for a`BuildSubset` | ||
| // and get the destination from there but there are other places that need | ||
| // refactoring in that way as well. | ||
| let buildParameters = if target.buildTriple == .tools { |
…t builds Supersedes swiftlang#7629
|
@swift-ci please test |
|
@swift-ci please test Windows platform |
MaxDesiatov
reviewed
Jun 9, 2024
|
Yeah, I need to figure out where to put the tests for this… |
|
@MaxDesiatov I added tests to cross-compilation suite and build operation. While doing that I had an idea:
WDYT? |
|
@swift-ci please test |
MaxDesiatov
approved these changes
Jun 10, 2024
SGTM |
|
@xedin would you be able to confirm that this issue is fixed in this PR? rdar://129400066 |
|
@MaxDesiatov Indeed it does! |
…stination:)` behavior
|
🤦 forgot to stage |
|
@swift-ci please test |
|
@MaxDesiatov I'll follow-up with optional |
|
@swift-ci please test Windows platform |
This was referenced Jun 10, 2024
xedin
added a commit
that referenced
this pull request
Jun 14, 2024
…`Modu… (#7668) …lesGraph.{product, target}(...)` to use optional destination - Explanation: Follow-up to #7646 This is mostly NFC change. It makes more sense to default `destination` to "undefined" when applicable because it's not always possible to know intended destination based on user input. This kind of design makes more sense for internal APIs, instead of having users to pass `.destination` even though it might not be always correct. - Main Branch PRs: #7650 - Risk: Very Low - Reviewed By: @MaxDesiatov - Testing: Existing test-cases were modified and new tests were added.
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 a temporary fix until we can figure out a proper way to
handle situations were all we get is a name of a product or a
target.
Motivation:
Callers or
ModulesGraph.{product, target}(for:destination:)cannot always know the rightdestinationto use at the moment because i.e. for test products and targets its contextual. We need a proper fix for this at the level or BuildSystem but for now sinking the logic down intoModulesGraphis the safest option.Modifications:
ModulesGraph.{product, target}(for:destination:)can handle fallback if product/target turn out to be a macro, a plugin or a test.Result:
--targetand--productoptions should work correctly regardless of underlying product/target kind.Resolves: rdar://129400066