Using ':' as the option delimiter breaks Windows build for some plugins

[timleung22]

For plugins that accept options for configuration of, say file location. One would sometimes set something like myplugin { option "${projectDir}"/src/main/resources/mytemplate" }

And that breaks in Windows because the plugin is forming a command with stuff like myplugin_out=C:/myproject/src/main/resources/mytemplate:... and that breaks because the protobuf plugin now just pass myplugin_out=C to the plugin myplugin as it parses the options expecting ":" are delimiters.

Maybe it should use a different character for delimiter, something that does not cause platform directory parth issue.

[zhangkun83]

@xfxyjwf we currently use : as the delimiter between plugin options and the output path, e.g., grpc_out=nano=true:build/generated/java. It becomes a problem under windows as the path may also contain :. Any suggestion?

[timleung22]

":" is definitely not good. Maybe "|" and document that's a separator?

[xfxyjwf]

I guess we can't change to use a different separator because it's not backwards compatible. I think you can probably make use of the "---xxx_opt" flag:

$ protoc --myplugin_opt=C:/myproject/src/main/resources/mytemplate --myplugin_out=... ...

That way the option containing ":" should be passed to the plugin as is.

[zhangkun83]

Thanks @xfxyjwf . At which protoc version was the --xxx_opt flag added?

[xfxyjwf]

It was added in this commit: https://github.com/google/protobuf/commit/59cd5d0e26c180117d9d5fe16be536e63d29e332

Released in protobuf 3.2.0.

[zhangkun83]

I misunderstood the case. The offending : is in the plugin options, not in the xxx_out path. Since --xxx_opt is not available on lower version of protoc, the Protobuf Gradle Plugin can generate command lines with --xxx_opt only if there is : in the options.

[marcoferrer]

This issue has impacted some users of a plugin I author. I submitted a PR that checks if the version of protoc plugin configured is compatible and uses the opt flag instead. This isn’t fool proof solution by any means since it only works if they configure the locator via artifact notation. I figured some support is better than none.

[akryvtsun]

We have relative problem in our project (I've described it here https://stackoverflow.com/q/69853032/2313177). Could you advice a workaround?

[voidzcy]

If I understand this correctly, this really is something that happens in the protoc compiler, caused by how --xxx_out=option1,option2:/path/to/output is interpreted. If option1 or option2 contains :, protoc is screwed up. Same problem exists even you use protoc directly. I'd suggest opening an issue to protobuf.

@akryvtsun Does your kotlin_service_gen option support relative path? It it does, you may try feeding in a relative path to avoid having things like C: in the option value.