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

Support vending products that are backed by binaryTargets #5810

Merged
merged 1 commit into from
Oct 27, 2022

Conversation

neonichu
Copy link
Contributor

@neonichu neonichu commented Oct 12, 2022

This adds support for vending an executable product that consists solely of a binary target that is backed by an artifact bundle. This allows vending binary executables as their own separate package, independently of the plugins that are using them.

rdar://101096803

@neonichu neonichu self-assigned this Oct 12, 2022
@neonichu neonichu added the WIP Work in progress label Oct 12, 2022
@neonichu
Copy link
Contributor Author

@swift-ci please smoke test

@neonichu
Copy link
Contributor Author

neonichu commented Oct 13, 2022

Some tests need updating due to new diagnostic, but this one surprises me a bit:

<EXPR>:0: error: PluginTests.testLocalAndRemoteToolDependencies : threw error "signalled(4): /home/build-user/swiftpm/.build/x86_64-unknown-linux-gnu/debug/swift-package --package-path /tmp/Miscellaneous_Plugins_PluginUsingLocalAndRemoteTool.QzzITS/MyLibrary --configuration debug plugin my-plugin output:
    Commands/SwiftPackageTool.swift:1083: Fatal error: no product named RemoteTool

I wonder if reachableProducts is not considering plugin dependencies right now?

@neonichu neonichu force-pushed the support-binary-executable-products branch 2 times, most recently from 5fbbcb9 to 799aeee Compare October 27, 2022 03:36
@@ -638,6 +638,11 @@ public final class BinaryTarget: Target {
}
}

public var containsExecutable: Bool {
// FIXME: needs to be revisited once libraries are supported in artifact bundles
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I opted to not open this can of worms here since right now .artifactsArchive implies that there is an executable. Addressing this required too many changes that are completely unrelated to this PR and which should be done once we implement support for libraries in artifact bundles.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is fair, but would be nice if there was some kind of associated data on the artifactsArchive that would allow us to throw an error if it is not an executable. eg .artifactsArchive(type:) not sure if that is the can of warms tho :)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yah, that was my approach, but it did require a bunch of changes 🪱 Could be a good change for a separate PR, though.

}
// For an executable target we create a `builtTool`.
else if target.type == .executable {
// TODO: How do we determine what the executable name will be for the host platform?
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note: I deleted this TODO because supporting the case where plugins work when the target platform isn't the host requires significant work in SwiftPM's build system.

let (_, validationDiagnostics) = try loadAndValidateManifest(content, observabilityScope: observability.topScope)
XCTAssertNoDiagnostics(observability.diagnostics)
testDiagnostics(validationDiagnostics) { result in
result.check(diagnostic: "invalid type for binary product 'FooLibrary'; products referencing only binary targets must have a type of 'library'", severity: .error)
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This diagnostic can longer be emitted for this particular case, because we cannot know whether a binary target is vending an executable or a library during manifest parsing since we need to crack open the referenced artifact to determine that. There will still be a diagnostic for this case, but it is handled by PackageBuilder and already covered by other existing tests.

@neonichu neonichu changed the title WIP: Support vending products that are backed by binaryTargets Support vending products that are backed by binaryTargets Oct 27, 2022
@neonichu neonichu removed the WIP Work in progress label Oct 27, 2022
@neonichu neonichu marked this pull request as ready for review October 27, 2022 03:44
@neonichu
Copy link
Contributor Author

@swift-ci please smoke test

@neonichu neonichu force-pushed the support-binary-executable-products branch from 799aeee to 45f6c40 Compare October 27, 2022 04:55
@neonichu
Copy link
Contributor Author

@swift-ci please smoke test

Copy link
Contributor

@tomerd tomerd left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

overall looks good. some small suggestions. would be good to get @abertelrud review as he knows this part of the code best

This adds support for vending an executable product that consists solely of a binary target that is backed by an artifact bundle. This allows vending binary executables as their own separate package, independently of the plugins that are using them.

rdar://101096803
@neonichu neonichu force-pushed the support-binary-executable-products branch from 45f6c40 to 47aefe7 Compare October 27, 2022 17:07
@neonichu
Copy link
Contributor Author

@swift-ci please smoke test

@neonichu neonichu merged commit c1bfac6 into main Oct 27, 2022
@neonichu neonichu deleted the support-binary-executable-products branch October 27, 2022 19:48
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.

4 participants