Large number of proto files leads to generate failure on Windows #167
Assignees
Labels
Comments
|
As I did more digging, I realized this may be a limitation of the protoc compliler: |
zhangkun83
pushed a commit
that referenced
this issue
Nov 22, 2017
Spread proto generation over multiple protoc calls on systems that limit command line length, e.g., Windows. Once the command length exceeds the OS limit, it calls with the current arguments and resets the builder. This is related to #167, allowing this issue to be avoided when many proto files are present, until protocolbuffers/protobuf#274 is completed.
|
It looks like protocolbuffers/protobuf#274 has been fixed in 3.5.0+. |
|
Consider it fixed by #174 |
zhangkun83
pushed a commit
to zhangkun83/protobuf-gradle-plugin-1
that referenced
this issue
Nov 7, 2018
Spread proto generation over multiple protoc calls on systems that limit command line length, e.g., Windows. Once the command length exceeds the OS limit, it calls with the current arguments and resets the builder. This is related to google#167, allowing this issue to be avoided when many proto files are present, until protocolbuffers/protobuf#274 is completed.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Windows has a relatively small command line length. We have a lot of proto files. When the plugin tries to make the call to generate, we get an error because the command line that the plugin tries to call is too long. When I printed out debug logging, I saw it was because it places each proto file on the command line.
Is there a way that a directory can be used instead of listing every proto file on the command line? That way a directory can be passed to the command instead of a huge amount of file paths.
Edit, adding in the protoc used:
protobuf { protoc { artifact = 'com.google.protobuf:protoc:3.3.0' } }The text was updated successfully, but these errors were encountered: