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

windows: write arguments to protoc to a file #347

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

pieter-bos
Copy link

A colleague on windows noticed an error in our build to this effect:

java.io.IOException: Cannot run program "C:\Users\Pieter\AppData\Local\protocbridge\protocbridge\cache\v1\protoc-windows-x86_64-3.19.2.exe": CreateProcess error=206, The filename or extension is too long

This occurs on windows when the whole process invocation exceeds 32767 bytes. Since protobuf v3.5.0 you can pass arguments via a file instead, by specifying an argument @<filename>, so this PR proposes to just always do that when running protoc on windows.

@pieter-bos
Copy link
Author

@thesamet any chance you could have a look?

@thesamet
Copy link
Contributor

thesamet commented May 9, 2024

I committed 20c99d1 that adds a method to transform a ProtocRunner to one that writes the args to a file, based on the code you provided. Then users, can using this runner from build.sbt like this:

Compile / PB.runProtoc := protocbridge.ProtocRunner.withParametersAsFile((Compile / PB.runProtoc).value)

Can we test that it works for you? Add to your project/plugins.sbt a dependency on the snapshot version of protoc-bridge:

libraryDependency += "com.thesamet.scalapb" %% "protoc-bridge" % "0.9.7+12-20c99d1d-SNAPSHOT"

and then implement the runProtoc setting describe above in build.sbt. I realize it's not as automated as the original PR, however with Windows I've been getting multiple environment-specific hard to reproduce issues over time that I wouldn't like to materially change how it works for everyone.

@pieter-bos
Copy link
Author

Thanks! I can't test it out immediately in our build because we use mill, which has a different entry point for scalapbc here. I'll try to hack in a solution to see if it works, which I think is sufficient insofar it concerns protoc-bridge, but I think a proper solution includes making mill-contrib-scalapblib call scalapbc more like the sbt plugin does.

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.

2 participants