Plugin doesn't have access to binary - Package Manager Extensible Build Tools (SE-0303 and SE-0305)

Evolution Discussion
,
1

I' have implemented the SwiftGen example from Package Manager Extensible Build Tools with a proper zip file for the binary target according to SE-0305.

However, as soon as I use the plugin in any other swift package I receive the error: Plugin does not have access to a tool named ‘swiftgen’. Are there any access issues known for binaryTarget plugins? Please find the example implementation here: Comparing SwiftGen:stable...Kondamon:stable · SwiftGen/SwiftGen · GitHub

let package = Package(
    name: "Test",
    platforms: [.iOS("13.0")],
    products: [
        .library(
            name: "Test",
            targets: ["Test"]),
    ],
    dependencies: [
      .package(url: "https://github.com/Kondamon/SwiftGen", branch: "stable")
    ],
    targets: [
        .target(
            name: "Test",
            plugins: [
                .plugin(name: "SwiftGenPlugin", package: "SwiftGen")
            ]
        ),
        .testTarget(
            name: "TestTests",
            dependencies: ["Test"])
    ]
)
3 Likes
2

SwiftPM should definitely provide some better functionality to help debug this kind of issue. In this case it looks as if the problem is that the info.json in the artifact archive lists the name of the tool as "SwiftGenBinaryTarget" and not "swiftgen". So the info.plist should be changed to "swiftgen" as the key under "artifacts".

There is also an example at GitHub - abertelrud/swiftpm-buildtool-plugin-examples: Some examples of SwiftPM build tool plugins to go along with SE-0303 + SE-0325 that can be used as a template. It does have the binary inline, which is of course usually not recommended (it's better to do what you have done and host the binary separately).

3 Likes
3

In this case I'm guessing that even just listing the tools that it did have access to in the error message would have helped. That should be quick to address, even before anything more sophisticated.

3 Likes
4

Does anybody know if there is a way to determine which tools context.tool has access to? We are using a context.tool(named: "git"), which works for some folks, but not for others. Trying to figure out how swift gets access to tools. TIA

5

Have those where it can't be found installed the Command Line Tools? I would guess those people are using git installed through brew or a GUI tool, and it's not otherwise available in the default environment. (I believe the command line tools version is, as it's in /usr/bin/git.) Generally for these sorts of tools you'll get the default environment defined by /etc/profile but not your custom environment from .profile or .zprofile, but someone else can answer the specific question about SPM.

6

Hi Jon - thanks for the response. It seems like everybody's is installed in /usr/bin/git, although still doesn't work for everybody. Will look into command line tools - thanks

7

which git should tell you what they're actively using, and then anyone who isn't using /usr/bin/git by default should check to see whether that is a usable version or a stub that's filled in by the Command Line Tools.

1 Like
8

Since this thread keeps popping up in search engines and ais: Could anyone share how to address this issue?

1 Like
9

Also wondering

10

I just found this out today, and I hope my explanation will be helpful to others.

It appears that Xcode/SPM generates a proper log message, which can be copied using the following menu item:

Screenshot 2024-07-18 at 14.35.17
Screenshot 2024-07-18 at 14.35.171936×762 171 KB

In my case the log message contained this:

working directory:
   /Users/tib/grpc
tool mapping:
   protoc-gen-swift: /${BUILD_DIR}/${CONFIGURATION}/protoc-gen-swift
tool search paths:
   /Applications/Xcode-beta.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
   /Applications/Xcode-beta.app/Contents/Developer/usr/bin
   /bin
   /sbin
   /usr/bin
   /usr/sbin

Plugin does not have access to a tool named ‘protoc’

Build stopped    18/07/2024, 14:33    0.3 seconds

Since SIP is enabled on my device and I’m unsure if there is an environment variable to use for injecting other paths, I simply linked the protoc command under the Xcode bin directory:

ln -snfv /opt/homebrew/bin/protoc /Applications/Xcode-beta.app/Contents/Developer/usr/bin/protoc

After this, I restarted Xcode, and voilà, the plugin worked again.

Feature request:
It would be great if Xcode could include the /usr/local/bin directory by default or if we could set an environment variable like SPM_TOOL_PATH_LOOKUP=/opt/homebrew/bin for the builds.

1 Like