Skip to content
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

Merged
merged 17 commits into from
Feb 6, 2021

Conversation

krzyzanowskim
Copy link
Contributor

@krzyzanowskim krzyzanowskim commented Jan 20, 2021

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:

  • add optional delegate to SPMBuildCore.BuildSystem
  • implement delegate calls for BuildOperation and XcodeBuildSystem

@abertelrud
Copy link
Contributor

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?

@krzyzanowskim
Copy link
Contributor Author

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?

the delegate queue is already there (frankly, I don't use it, but will by the time I'll finish PR).

@abertelrud
Copy link
Contributor

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?

the delegate queue is already there (frankly, I don't use it, but will by the time I'll finish PR).

Great, thanks! Didn't see that there was a queue already; I was only looking at the new callsites. Thanks!

@krzyzanowskim krzyzanowskim marked this pull request as ready for review January 20, 2021 22:04
@tomerd
Copy link
Contributor

tomerd commented Jan 28, 2021

@krzyzanowskim thanks for putting this together, do you feel it is ready for review? cc @abertelrud

@tomerd
Copy link
Contributor

tomerd commented Jan 28, 2021

@swift-ci please smoke test

@krzyzanowskim
Copy link
Contributor Author

@tomerd yes, please do.

Copy link
Contributor

@abertelrud abertelrud left a 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.

@@ -29,7 +32,7 @@ public final class BuildOperation: PackageStructureDelegate, SPMBuildCore.BuildS
let packageGraphLoader: () throws -> PackageGraph

/// The build delegate reference.
Copy link
Contributor

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.

Copy link
Contributor Author

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 ?

Copy link
Contributor

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!

@abertelrud
Copy link
Contributor

It looks as if the failures are because the CMake scripts need to be updated (for the new files).

@tomerd
Copy link
Contributor

tomerd commented Feb 1, 2021

@krzyzanowskim lets get CMake fixed up and add the relevant comments so we can merge this

@tomerd
Copy link
Contributor

tomerd commented Feb 4, 2021

@swift-ci please test

@tomerd
Copy link
Contributor

tomerd commented Feb 4, 2021

@swift-ci please smoke test

@tomerd
Copy link
Contributor

tomerd commented Feb 4, 2021

@abertelrud please confirm changes look good based on you previous feedback so we can merge this

@abertelrud
Copy link
Contributor

@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.

@abertelrud
Copy link
Contributor

@swift-ci please smoke test

1 similar comment
@tomerd
Copy link
Contributor

tomerd commented Feb 5, 2021

@swift-ci please smoke test

@abertelrud
Copy link
Contributor

Looks like SourceKit-LSP is affected:

10:20:48 
/Users/buildnode/jenkins/workspace/swift-package-manager-PR-macos-smoke-test/branch-main/sourcekit-lsp/Sources/SKSwiftPMWorkspace/SwiftPMWorkspace.swift:47:29: error: 'BuildSystemDelegate' is ambiguous for type lookup in this context
10:20:48   public weak var delegate: BuildSystemDelegate? = nil
10:20:48                             ^~~~~~~~~~~~~~~~~~~
10:20:48 /Users/buildnode/jenkins/workspace/swift-package-manager-PR-macos-smoke-test/branch-main/swiftpm/Sources/SPMBuildCore/BuildSystemDelegate.swift:14:17: note: found this candidate
10:20:48 public protocol BuildSystemDelegate: AnyObject {
10:20:48                 ^
10:20:48 /Users/buildnode/jenkins/workspace/swift-package-manager-PR-macos-smoke-test/branch-main/sourcekit-lsp/Sources/SKCore/BuildSystemDelegate.swift:17:17: note: found this candidate
10:20:48 public protocol BuildSystemDelegate: AnyObject {
10:20:48                 ^

@abertelrud
Copy link
Contributor

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?

@benlangmuir
Copy link
Contributor

swiftlang/sourcekit-lsp#370

@swift-ci please smoke test

@benlangmuir
Copy link
Contributor

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?

I changed sourcekit-lsp (swiftlang/sourcekit-lsp#370) to use a fully qualified reference, which seemed to be sufficient.

@krzyzanowskim
Copy link
Contributor Author

4wvy0h

@tomerd tomerd merged commit 6475635 into swiftlang:main Feb 6, 2021
neonichu added a commit to neonichu/swift-package-manager that referenced this pull request Feb 9, 2021
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.
neonichu added a commit that referenced this pull request Feb 9, 2021
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants