In https://codereview.chromium.org/1947373002/ I hacked a proto stub generator in python. The current pipeline is .proto file -> (official protoc binary) -> python file -> (my tracing_protoc.py) -> C++-fast stub.
The reason for doing that is I don't want to rewrite a .proto parser.
This looked to be a neat idea, until, in an internal thread, haberman@ pointed out that:
> We try to write our code generators in C++ generally and use the standard framework. It lets you reuse the .proto file parser and lets you generate your code with protoc directly. Here is an example:
https://github.com/google/protobuf/blob/master/src/google/protobuf/compiler/test_plugin.cc
So my question now is:
Can we look into that plugin architecture and see if that is suitable to do what I'm trying to do in python (to generate the fast stubs)? That would be way cleaner.
Before doing all the work (of converting my python generator to C++ plugin) we need to understand how that works form a build infrastructure viewpoint.
Does it need to be compiled in as part of the protoc executable?
Can it be compiled as a standalone executable? I think this is the case by looking at test_plugin target in third_party/protobuf/BUILD.
If all this holds, can you try to do the following:
- Create a tracing_protoc binary which works in principle like the aforementioned test_plugin.
- Make sure that all the code for that lives outside of third_party/protobuf (we don't want to ask owners of third_party/protobuf to fork the project internally and add stuff there which is not upstream)
As a first step we should see if you can define a tracing_protoc executable target in base/BUILD.gn which just uses the existing mock_code_generator.cc. This will give you the guarantee that we can create our alternative executable without having to touch third_party/protobuf
As a second step, get rid of mock_code_generator and try to rewrite my python generator in C++ using that plugin architecture.
Comment 1 by primiano@chromium.org
, May 17 2016OK I think what we want here is an executable target outside of third_party/protobuf that links against the protoc_lib target (defined in third_party/protobuf/BUILD.gn). In other words, this is the current default protoc (from third_party/protobuf/BUILD.gn) ----- executable("protoc") { sources = [ "src/google/protobuf/compiler/main.cc", ] configs -= [ "//build/config/compiler:chromium_code" ] configs += [ "//build/config/compiler:no_chromium_code" ] cflags = protobuf_lite_cflags deps = [ ":protoc_lib", # Default manifest on Windows (a no-op elsewhere). "//build/win:default_exe_manifest", ] } ----- Sounds like we want something similar, not use compiler/main.cc but our own special code which lives outside of third_party/protobuf.