Introduce subcommand for jextract to prevent linking Foundation#624
Introduce subcommand for jextract to prevent linking Foundation#624madsodgaard wants to merge 7 commits intoswiftlang:mainfrom
Conversation
| jextractOutputFiles += [javaSourcesFile] | ||
| // NOTE: javaSourcesFile is intentionally NOT added to jextractOutputFiles. | ||
| // Adding a non-Swift file as a build command output causes SPM to bundle it | ||
| // as a module resource, which triggers resource_bundle_accessor.swift generation |
| arguments: arguments, | ||
| inputFiles: [configFile] + swiftFiles, | ||
| outputFiles: jextractOutputFiles | ||
| outputFiles: jextractOutputFiles, |
There was a problem hiding this comment.
pretty sure formatter will dislike this?
There was a problem hiding this comment.
okey I'm honestly confused with swift-format sometimes... 😅
| // inputFiles includes the Swift outputs from jextract so that SPM knows | ||
| // this command must run after jextract finishes. | ||
| var javaCallbacksArguments = [ | ||
| "java-callbacks-build", |
There was a problem hiding this comment.
Do we HAVE to do it all int one huge mega step? Can we not invoke multiple commands one by one? I'd like to make this hidden in command line somehow...
There was a problem hiding this comment.
Hm, what would we benefit from writing multiple commands? As this is only intended for internal use and a workaround for the SwiftPM limitation.
| @preconcurrency import SystemPackage | ||
| #endif | ||
|
|
||
| /// Builds Swift-Java callbacks in a single command: |
There was a problem hiding this comment.
Put a huge WORKAROUND: rdar://172649681 if we invoke commands one by one with java outputs SwiftPM will link Foundation here
There was a problem hiding this comment.
Actually, would be good if you filed an issue on swiftpm explaining this behavior, might be better to track that way coming from you directly as well
There was a problem hiding this comment.
ktoso
left a comment
There was a problem hiding this comment.
Can you please construct a Linkage test that would show this problem? I'd like to not regress on it by accident
| /// Gradle output directories) as module resources, which would trigger | ||
| /// resource_bundle_accessor.swift generation and pull Foundation.Bundle into the binary. | ||
| extension SwiftJava { | ||
| struct JavaCallbacksBuildCommand: AsyncParsableCommand { |
There was a problem hiding this comment.
Man I really dislike this command... we'll have to copy around and keep it updated constantly :-\
Before we merge this, can we make sure we can't avoid it? How about just ignoring the java outputs, does swiftpm prevent things from working if we just pretend they don't exist but we write them anyway?
There was a problem hiding this comment.
The problem is I am guessing that SwiftPM uses the input/output to derive the dependencies between the build commands. So, I am afraid that it will run the builds in the wrong order.
Alternatively, if its only using it for stale checks, that means that if we remove them from the outputs, we would retrigger those commands on each invocation of the build plugin. Maybe someone from the SwiftPM team can confirm the behaviour here?
| ResolveCommand.self, | ||
| WrapJavaCommand.self, | ||
| JExtractCommand.self, | ||
| JavaCallbacksBuildCommand.self, |
There was a problem hiding this comment.
Can you check how we can hide this form --help? Alternatively, _ prefix it or do something to its name in argument parser etc.
There was a problem hiding this comment.
That's what the shouldDisplay: false does:
OVERVIEW: Generate sources and configuration for Swift and Java interoperability.
USAGE: swift-java <subcommand>
OPTIONS:
-h, --help Show help information.
SUBCOMMANDS:
configure Configure and emit a swift-java.config file based on an input dependency or jar file
resolve Resolve dependencies and write the resulting swift-java.classpath file
wrap-java Wrap Java classes with corresponding Swift bindings.
jextract Wrap Swift functions and types with Java bindings, making them available to be called from Java
Resolves #619
Specifying any non Swift files as build plugin outputs, will make SPM generate a bundle accessor file which imports Foundation unconditionally.
To solve this, we introduce a new subcommand that handles the callback part of the JExtract build plugin.