2016-04-03 21:00 GMT+02:00 Elvis Stansvik <[email protected]>: > 2016-04-03 20:17 GMT+02:00 Feng Xiao <[email protected]>: >> 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.
Anyone with more info on this? Speaking about current versions of protobuf now: Will I really have to replicate the arg parsing / SourceTree construction of the compiler in my own plugin code to achieve this? Elvis > > Elvis > >> >> On Sun, Apr 3, 2016 at 3:32 AM, Elvis Stansvik <[email protected]> wrote: >>> >>> 2016-04-01 7:50 GMT+02:00 Elvis Stansvik <[email protected]>: >>> > Hi Feng, >>> > >>> > 2016-03-31 22:28 GMT+02:00 Feng Xiao <[email protected]>: >>> >> >>> >> >>> >> On Wed, Mar 30, 2016 at 9:40 AM, Elvis Stansvik <[email protected]> >>> >> 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 [email protected]. >>> >>> To post to this group, send email to [email protected]. >>> >>> 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 [email protected]. >>> To post to this group, send email to [email protected]. >>> 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/protobuf. For more options, visit https://groups.google.com/d/optout.
