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.

Reply via email to