I think it would be really helpful to be able to override anything in
FileOptions from the command line, at least. I'm not sure if anyone
would really want to override options at other levels (Message/Field/
Enum/Service/Method)... but maybe something like:
# apply a file-level option to specific files
protoc +file+foo.proto,bar.proto+optimize_for=SPEED foo.proto
# apply a file-level option to all files
# Apply a message-level option to specific messages
protoc +message+Foo,Bar+message_set_wire_format=1 foo.proto bar.proto
# Apply a message-level option to specific messages in specific files
foo.proto bar.proto baz.proto
# Apply a message-level option to all messages in a set of files
foo.proto bar.proto baz.proto
# Apply a message-level option to all messages in all files
protoc +message+message_set_wire_format=1 foo.proto bar.proto
# Apply a field-level option to specific fields in specific messages
in specific files (ugh)
protoc +field+foo.proto:Foo.bar+packed=1 foo.proto
# Apply a field-level option to all fields in all files (???)
protoc +field+packed=1 foo.proto
# Apply a field-level option to a particular field in all messages in
all files (NO!?)
protoc +field+:.baz+packed=1 foo.proto bar.proto
I don't know why someone would apply a field-level option to all
fields in all files, but... it would technically make it possible to
compile a set of .proto files with packed=true on all fields (assuming
protoc doesn't abort compilation if packed=true is applied to a non-
repeated or non-primitive field).
I don't have a strong opinion about delimiters in the option syntax; I
just chose some that should hopefully work without ambiguity.
On Jan 31, 6:58 pm, Kenton Varda <ken...@google.com> wrote:
> We'd like to make it possible to override options from the command-line, but
> no one has gotten around to implementing it. How best to do this is
> unclear, particularly when you consider message-level and field-level
> options as well. What should the flag syntax be to, say, set "packed =
> true" on all repeated primitive fields? Or just on the field
> "MyMessage.some_field"? (The "packed" option may not be the best example,
> but let's imagine we had other field options that really do make sense to
> set on the command line.)
> Ideally, I'd like any solution we come up with to solve the general problem,
> or at least have a clear way to expand it to cover all option types in the
> future even if we only support file-level options initially.
> On Sun, Jan 31, 2010 at 11:28 AM, Chris <hsifdr...@gmail.com> wrote:
> > The fact that options are defined within the .proto file doesn't make
> > sense in some situations to me:
> > While I do see the point of putting an "java_outer_classname"
> > definition into a file, because there is a strong relation between the
> > message and what we call it.
> > However "optimize_for" for example seems misplaces in the code: isn't
> > that supposed to be a compile option? Consider the situation where you
> > want to compile the same .proto sources twice: once for a mobile
> > device using the "lite" version and the other time speed optimized,
> > but not "lite" as you want to use reflection.
> > Or it is possible to pass these options to the compiler directly?
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Protocol Buffers" group.
> > To post to this group, send email to proto...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > protobuf+unsubscr...@googlegroups.com<protobuf%2bunsubscr...@googlegroups.com>
> > .
> > For more options, visit this group at
You received this message because you are subscribed to the Google Groups
"Protocol Buffers" group.
To post to this group, send email to proto...@googlegroups.com.
To unsubscribe from this group, send email to
For more options, visit this group at