-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
BuildSystem delegate API #3209
BuildSystem delegate API #3209
Conversation
This looks like a good addition to me! One question: what are the guarantees about when the delegate methods will be called, e.g. are they guaranteed to be called all on the same queue so that there won't be any overlap between them? I'm not that familiar with the concurrency behavior of the callbacks from llbuild; perhaps that's already part of the contract, but if not, would it make sense to have a serial queue that they're all invoked on so that ever client doesn't have to implement its own concurrency control? |
the delegate |
Great, thanks! Didn't see that there was a queue already; I was only looking at the new callsites. Thanks! |
@krzyzanowskim thanks for putting this together, do you feel it is ready for review? cc @abertelrud |
@swift-ci please smoke test |
@tomerd yes, please do. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks good to me; thank you for the additions! I had a couple of questions but they are minor.
Sources/Build/BuildOperation.swift
Outdated
@@ -29,7 +32,7 @@ public final class BuildOperation: PackageStructureDelegate, SPMBuildCore.BuildS | |||
let packageGraphLoader: () throws -> PackageGraph | |||
|
|||
/// The build delegate reference. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since there are now two different delegates, it would be great to differentiate between their purpose in the comments. I think the one here is the one that performs required actions on behalf of the build system, whereas the new one is just advisory, IIUC.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
naming is hard indeed, especially that "build system" is ambiguous in the context. There's llbuild build system, and there's SPM build system. Would that work: 7e4f0bd ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, that's clearer. Thanks!
It looks as if the failures are because the CMake scripts need to be updated (for the new files). |
@krzyzanowskim lets get CMake fixed up and add the relevant comments so we can merge this |
@swift-ci please test |
@swift-ci please smoke test |
@abertelrud please confirm changes look good based on you previous feedback so we can merge this |
Thanks @tomerd they look good to me. As far as I am concerned this can be merged. |
@swift-ci please smoke test |
1 similar comment
@swift-ci please smoke test |
Looks like SourceKit-LSP is affected:
|
Not sure if there is an interim change that can be put into SourceKit-LSP to avoid the ambiguity, or whether this PR needs to change. @benlangmuir what would you suggest? |
@swift-ci please smoke test |
I changed sourcekit-lsp (swiftlang/sourcekit-lsp#370) to use a fully qualified reference, which seemed to be sufficient. |
This got broken in swiftlang#3209 which was using `llbuildSwift` unconditionally. This is easy to miss, but in some environments we set `SWIFTPM_LLBUILD_FWK` and link against a pre-built framework which will only have the module `llbuild`. We should improve the testing here and build in both modes to avoid this kind of breakage in the future.
This got broken in #3209 which was using `llbuildSwift` unconditionally. This is easy to miss, but in some environments we set `SWIFTPM_LLBUILD_FWK` and link against a pre-built framework which will only have the module `llbuild`. We should improve the testing here and build in both modes to avoid this kind of breakage in the future.
BuildSystem progress notification API via delegate
Motivation:
The
BuildOperation
acts as a black box, that makes it impossible to get meaningful notifications about the build events.forum thread: https://forums.swift.org/t/how-buildsystem-api-is-accessible-for-the-clients/43787
Modifications:
Introduce
BuildSystemDelegate
that can be used to track the progress of the build operation by the clients.Result:
delegate
toSPMBuildCore.BuildSystem
BuildOperation
andXcodeBuildSystem