[Explicit Module Builds] Add support for header dependencies of binary Swift module dependencies #1375
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
|
@swift-ci test |
artemcm
force-pushed
the
TransitivePCHDepsOfBinaryModules
branch
from
c772569 to
adb2f2c
Compare
|
@swift-ci test |
cachemeifyoucan
approved these changes
Jun 13, 2023
| @@ -228,6 +228,14 @@ private extension SwiftScan { | |||
| try getOptionalPathDetail(from: moduleDetailsRef, | |||
| using: api.swiftscan_swift_binary_detail_get_module_source_info_path) | |||
|
|
|||
| let headerDependencies: [TextualVirtualPath]? | |||
| if supportsBinaryModuleHeaderDependencies { | |||
There was a problem hiding this comment.
Do you need to do this check as getOptionalPathArrayDetails will return the same result?
nkcsgexi
approved these changes
Jun 13, 2023
rdar://109426410 |
artemcm
force-pushed
the
TransitivePCHDepsOfBinaryModules
branch
from
adb2f2c to
f4b528e
Compare
|
@swift-ci test |
artemcm
force-pushed
the
TransitivePCHDepsOfBinaryModules
branch
from
f4b528e to
d2d781a
Compare
|
@swift-ci test |
…y Swift module dependencies When we encounter a pre-built Swift binary module dependency (without an interface file), such module may have been built with a bridging header, which must still be present and is referenced by the binary .swiftmodule as either a .h or, more-likely, a pre-built .pch in a fully-explicit build. Clients must be able to know about such header dependencies in order to be able to import this binary module, because this binary module may be referencing types brought in via its bridging header. The build-system client (swift-driver) will then ensure these header dependencies are fed as inputs to all requiring compilation tasks. This adds support to the driver to query such header dependencies and feed them as inputs to all requiring compilation tasks.
|
@swift-ci test |
artemcm
force-pushed
the
TransitivePCHDepsOfBinaryModules
branch
from
d2d781a to
754672e
Compare
|
@swift-ci test |
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.
When we encounter a pre-built Swift binary module dependency (without an interface file), such module may have been built with a bridging header, which must still be present and is referenced by the binary .swiftmodule as either a .h or, more-likely, a pre-built .pch in a fully-explicit build.
Clients must be able to know about such header dependencies in order to be able to import this binary module, because this binary module may be referencing types brought in via its bridging header. The build-system client (swift-driver) will then ensure these header dependencies are fed as inputs to all requiring compilation tasks.
This adds support to the driver to query such header dependencies and feed them as inputs to all requiring compilation tasks.
Companion change to swiftlang/swift#66556