Introduce subcommand for jextract to prevent linking Foundation#624
Introduce subcommand for jextract to prevent linking Foundation#624ktoso merged 8 commits intoswiftlang:mainfrom
Conversation
| // 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.
There was a problem hiding this comment.
I meant finding some way to keep the previous workflow going rather than introducing this command
| @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
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?
There was a problem hiding this comment.
@dschaefer2 would you mind confirming we have no other way out here?
2 participants
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.