[Explicit Module Builds][Target Variant] Refactor build planning to allow for a second, separate emit-module task for the target variant #1856
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
VariantEmitModule
branch
from
6d351de to
95c6c6d
Compare
|
@swift-ci test |
artemcm
force-pushed
the
VariantEmitModule
branch
from
95c6c6d to
e1c9db6
Compare
|
@swift-ci test |
…llow for a second, separte emit-module task for the target variant This change allows builds that specify a variant triple and which must emit a target variant module to do so from within a single `swiftc` invocation when using Explicit Module Builds. This is an extensive refactor of the build planning procedure with respect to Explicit Module Builds: - Remove 'ExplicitDependencyBuildPlanner' global state from the 'Driver' instance - Instantiate a 'ExplicitDependencyBuildPlanner' instance at the beginning if build planning and propagate/thread this instance to all the required compilation task creation routines, all the way to 'addCommonFrontendOptions' - For '-target-variant' builds which emit a variant triple module, instantiate a whole separate explicit build planner, including performing a secondary dependency scan using the variant triple. Using this information: - Schedule variant triple module pre-compile dependency tasks - Schedule a variant triple PCH compilation task, if necessary - Schedule the variant emit-module task - Schedule the variant textual module verification task, if necessary
artemcm
force-pushed
the
VariantEmitModule
branch
from
e1c9db6 to
16688ae
Compare
|
@swift-ci test |
|
@swift-ci test Windows platform |
1 similar comment
|
@swift-ci test Windows platform |
| throws -> (VirtualPath.Handle?, VirtualPath.Handle?) { | ||
| let contextHash = try? explicitModulePlanner?.getMainModuleContextHash() | ||
| let chainedBridgingHeader = explicitModulePlanner?.chainedBridgingHeaderFile | ||
| let importedObjCHeader = try computeImportedObjCHeader(&parsedOptions, compilerMode: compilerMode, |
There was a problem hiding this comment.
computeImportedObjCHeader current does a file write to create the header. We don't want to write header every time we call this function.
Alternative is to have a new type that is similar to temporaryWithKnownContents but it is not a temporary.
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 change allows builds that specify a variant triple and which must emit a target variant module to do so from within a single
swiftcinvocation when using Explicit Module Builds.This is an extensive refactor of the build planning procedure with respect to Explicit Module Builds:
ExplicitDependencyBuildPlannerglobal state from theDriverinstanceExplicitDependencyBuildPlannerinstance at the beginning if build planning and propagate/thread this instance to all the required compilation task creation routines, all the way toaddCommonFrontendOptions-target-variantbuilds which emit a variant triple module, instantiate a whole separate explicit build planner, including performing a secondary dependency scan using the variant triple. Using this information: