On Friday, August 4, 2017 at 12:18:14 PM UTC-4, Ray Scott wrote:
>
> I don't know the internals of the protobuf architecture with respect to 
> plugins, or the compilation process, so I don't know where or why the 
> output source filename gets set.  I just know it would be useful to be able 
> to configure the resulting filename format.
>

My point was, if you are talking a file options (like prefix), it would be 
within the file, so it would have the same problem, something that is 
within the file changing what is generated, so just like a build system 
can't read the prefix, it wouldn't be able to read that option either.

TVL
 

>
>
> On Friday, 4 August 2017 14:57:56 UTC+1, Thomas Van Lenten wrote:
>>
>>
>> On Thursday, August 3, 2017 at 10:20:53 AM UTC-4, Ray Scott wrote:
>>>
>>> Or, you could make better use of your own options with a 
>>>
>>> objc_filename_style=[none || camel]
>>> objc_prefixed_filename= [no || yes]
>>>
>>> Now everyone wins. :-)
>>>
>>
>> Do you mean a file option?  That would still be within the file, so it 
>> has the same problems, no?
>>
>> TVL
>>
>>
>>>
>>> On Thursday, 3 August 2017 14:33:50 UTC+1, Thomas Van Lenten wrote:
>>>>
>>>> The prefix is documented 
>>>> <https://github.com/google/protobuf/tree/master/objectivec#objective-c-generator-proto-file-options>
>>>>  
>>>> to only be added to the symbols created within the file, it does not 
>>>> change 
>>>> the name of the file.  The compiler with recreate the file hierarchy it is 
>>>> given, so the files should be unique, and the prefix isn't needed from 
>>>> that 
>>>> pov.  Generally speaking, having something within the file change what 
>>>> files are generated makes things very difficult to integrate with build 
>>>> systems as build systems don't want to have to know how to parse/inspect 
>>>> all the files they may pass off to tools.  The fact that we do the camel 
>>>> case transform has already been flagged as an issue 
>>>> <https://github.com/google/protobuf/issues/864>, but it would break 
>>>> things to change that behavior at this point.
>>>>
>>>> On Thursday, August 3, 2017 at 5:34:07 AM UTC-4, Ray Scott wrote:
>>>>>
>>>>> Hi, 
>>>>>
>>>>> I'm new to Protocol Buffers, and I'm using gRPC within a iOS Framework 
>>>>> written in Objective-C. I found the useful proto3 option, 
>>>>> objc_class_prefix, for adding a 3+ character class prefix to the Objc 
>>>>> generated code. What I don't understand is why this class prefix (for 
>>>>> e.g. 
>>>>> "MYRPC") isn't used to name the generated pbobjc.h & pbobjc..m files too. 
>>>>>
>>>>> The only way I've found to get around this, unacceptably, is to append 
>>>>> to the snake case name so the file named "m_y_r_p_c_service.proto" is 
>>>>> converted to MYRPCService.pbobjc.h & MYRPCService.pbobjc.m. Of course, if 
>>>>> you change the protobuf option objc_class_prefix in the source, you'd 
>>>>> still 
>>>>> need to rename the files. Plus, if I use these proto files to generate 
>>>>> code 
>>>>> for a different language, the file naming convention may not be the same 
>>>>> as 
>>>>> for Apple's Obj-C convention. 
>>>>>
>>>>> Considering it's good style (and something Xcode does automatically) 
>>>>> to name your objc files with the class prefix, I would have thought this 
>>>>> would have applied to the generated source code files with protobufs. 
>>>>>
>>>>> Does anyone know how to achieve this file name prefixing without the 
>>>>> .proto file name hack?
>>>>>
>>>>

-- 
You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to protobuf+unsubscr...@googlegroups.com.
To post to this group, send email to protobuf@googlegroups.com.
Visit this group at https://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.

Reply via email to