2016-04-03 20:17 GMT+02:00 Feng Xiao <xiaof...@google.com>:
> Hi Elvis,
>
> I think preserving comments at the very top of the .proto file is something
> the protocol compiler should do. I remember this feature was requested
> inside Google as well and was implemented some time ago. Not sure if it's
> ported to the opensource repo though. If that's what you need, could you
> file a github issue? I'll double-check the status and follow-up on the
> issue.

Ah, that sounds like good news then. I filed:

    https://github.com/google/protobuf/issues/1385

I'd very much like an API to get the comment at the top of the file,
and a way to know that it really was the first thing in the file
(before any imports et.c.).

Thanks a lot for looking into this.

I'm of course still looking for some way that will work with current
releases of protobuf, as my tool supports versions back to 2.5.0. But
from the looks of it, I'm going to have to duplicate the input args /
-I parsing and build a mirror SourceTree, to be able to resolve file
names to on-disk names.

Elvis

>
> On Sun, Apr 3, 2016 at 3:32 AM, Elvis Stansvik <elvst...@gmail.com> wrote:
>>
>> 2016-04-01 7:50 GMT+02:00 Elvis Stansvik <elvst...@gmail.com>:
>> > Hi Feng,
>> >
>> > 2016-03-31 22:28 GMT+02:00 Feng Xiao <xiaof...@google.com>:
>> >>
>> >>
>> >> On Wed, Mar 30, 2016 at 9:40 AM, Elvis Stansvik <elvst...@gmail.com>
>> >> wrote:
>> >>>
>> >>> On Wednesday, March 30, 2016 at 2:12:46 AM UTC+2, Horst Noreick wrote:
>> >>>>
>> >>>> the compiler uses GOPATH from environment
>> >>>
>> >>>
>> >>> Hm, I think you may have misunderstood me. GOPATH seems to be some
>> >>> variable to control the paths searched by the Go language compiler.
>> >>>
>> >>> What I'm looking for is a way to determine (from the
>> >>> google::protobuf::FileDescriptor, or some other API accessible to
>> >>> protobuf
>> >>> compiler plugins) the full on-disk path to the directory that is
>> >>> considered
>> >>> the "source tree" of the currently processed file, so that I can
>> >>> construct
>> >>> the full on-disk path to it. The reason I need this is that my plugin
>> >>> needs
>> >>> to open the file to do some ad-hoc parsing of the file.
>> >>
>> >> Can you describe a bit more about what info do you need from the
>> >> original
>> >> file? If it's useful for documentation, we could consider adding that
>> >> to
>> >> FileDescriptorProto (like the SourceCodeInfo field) and send it along
>> >> to the
>> >> plugins.
>> >
>> > I'm afraid my requirement might be too specific to be considered.
>> >
>> > My use case is this:
>> >
>> > <Foo.proto>
>> > /// This file contains Foo and stuff.
>> > ///
>> > /// Blah blah.
>> > package some.package;
>> >
>> > message Foo {...}
>> >
>> > message Blah {...}
>> > <Foo.proto>
>> >
>> > or
>> >
>> > <Foo.proto>
>> > /**
>> >  * This file contains Foo and stuff.
>> >  *
>> >  * Blah blah.
>> >  */
>> > package some.package;
>> >
>> > message Foo {...}
>> >
>> > message Blah {...}
>> > <Foo.proto>
>> >
>> > where I need access to the documentation comment at the very top of
>> > the input .proto file. User's are using this to document the file as a
>> > whole.
>> >
>> > At the moment I've implemented this like this:
>> >
>> >
>> > https://github.com/estan/protoc-gen-doc/blob/master/src/main.cpp#L157-L225
>> >
>> > That is, by opening the file and parsing it out myself, but this will
>> > fail sometimes as I'm simply opening using FileDescriptor::name() as
>> > file name, not the full path. So I need a way to get the full resolved
>> > on-disk path to an input file.
>> >
>> > For many other comments, I'm making good use of
>> > SourceLocation::leading_comments and SourceLocation::trailing_comments
>> > to get the comments for messages, enums, fields et.c.
>> >
>> > Cheers,
>> > Elvis
>>
>> I've now searched quite thoroughly through the protobuf code, and
>> concluded that there's no way, directly or indirectly, for a plugin to
>> access the SourceTree used by the compiler (created in
>> command_line_interface.cc, line 750 [1]).
>>
>> This means that if a plugin author wants to get the on-disk path of
>> one of an input file, in a proper way, he/she must create a SourceTree
>> that mirrors the one used by the compiler. This means re-doing all the
>> command line parsing work the CommandLineInterface already does (or
>> well, the parsing of -I options and inputs) as well as the mapping of
>> virtual paths to disk paths, to make sure it represents an identical
>> SourceTree to the one used by the compiler. This work is quite
>> sophisticated and non-trivial (e.g. see also the
>> CommandLineInterface::MakeInputsBeProtoPathRelative(...) which would
>> need to be duplicated).
>>
>> I would therefore like to ask the GeneratorContext interface (in
>> compiler/code_generator.h), which is accessible to plugins, be given
>> something like a
>>
>>     virtual SourceTree *sourceTree();
>>
>> method, which can be used by plugins to access the SourceTree used by
>> the compiler.
>>
>> After that, getting the on-disk path of an input file described by a
>> FileDescriptor would be a simple matter of
>>
>>     std::string diskPath;
>>     sourceTree->VirtualFileToDiskFile(descriptor->name(), &diskPath);
>>
>> I can see two potential use cases where a plugin author wants to get
>> the on-disk file:
>>
>>   * My current use case: I need to do some custom ad-hoc parsing of the
>> file.
>>   * A documentation generator plugin may want to provide a link to the
>> .proto source code (similar to e.g. Doxygen).
>>
>> But I'm sure there are other use cases.
>>
>> What do you think, is this a reasonable request? The description of
>> the GeneratoContext interface is currently:
>>
>> // CodeGenerators generate one or more files in a given directory.  This
>> // abstract interface represents the directory to which the CodeGenerator
>> is
>> // to write and other information about the context in which the Generator
>> // runs.
>>
>> And I think the SourceTree fits quite well under "other information
>> about the context in which the Generator runs".
>>
>> Cheers,
>> Elvis
>>
>> [1]
>> https://github.com/google/protobuf/blob/master/src/google/protobuf/compiler/command_line_interface.cc#L750
>>
>> >
>> >>
>> >>>
>> >>>
>> >>> I don't think GOPATH will give me any of this.
>> >>>
>> >>> Cheers,
>> >>> Elvis
>> >>>
>> >>>
>> >>> --
>> >>> 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.
>> >>
>> >>
>>
>> --
>> 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.
>
>

-- 
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