The problem I keep running into here is that anything one proposes leaves
more to be desired.  If I can munge options, shouldn't I also be able to
munge types?  What if I want to take a message type, remove some fields that
I don't care about (so that I can drop some dependencies), change a
particular repeated field to [packed=true], and change the type name so that
it doesn't conflict with the original type?  All reasonable things to want
to do...

I was thinking that the way this should really be accomplished is with
scripts written in a real programming language which modify the
FileDescriptorProto (the parsed representation of a .proto).  You could
actually inject such a script today by writing it as a wrapper around a
plugin -- if only the standard code generators were plugins.

I wonder if we should make this usage model easier somehow.  We could
introduce filtering plugins that have a chance to modify the parsed files
before the code generator plugins are executed.

Of course, writing a filter plugin may be overkill when all you want is to
change a top-level file option.  So maybe we should provide a special case
just for file options since they'd be by far the most widely-used case.

On Tue, Mar 9, 2010 at 6:22 PM, Dave Bailey <d...@daveb.net> wrote:

> 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
> bar.proto baz.proto
>
> # apply a file-level option to all files
> protoc +file+optimize_for=SPEED
>
> # Apply a message-level option to specific messages
> protoc +message+Foo,Bar+message_set_wire_format=1 foo.proto bar.proto
> baz.proto
>
> # Apply a message-level option to specific messages in specific files
> protoc +message+foo.proto:Foo,bar.proto:Bar+message_set_wire_format=1
> foo.proto bar.proto baz.proto
>
> # Apply a message-level option to all messages in a set of files
> protoc +message+foo.proto:,bar.proto:+message_set_wire_format=1
> 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
> baz.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.
>
> -dave
>
> 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>
> <protobuf%2bunsubscr...@googlegroups.com<protobuf%252bunsubscr...@googlegroups.com>
> >
> > > .
> > > For more options, visit this group at
> > >http://groups.google.com/group/protobuf?hl=en.
>
> --
> 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
> http://groups.google.com/group/protobuf?hl=en.
>
>

-- 
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.
For more options, visit this group at 
http://groups.google.com/group/protobuf?hl=en.

Reply via email to