I currently have a file called addressbook.proto in next to my protoc.exe. I am having difficulty generating the .h and the .cc file. Here is what I am doing
protoc --cpp_out=c:\addressbook.proto
However I get the following response
Missing input file.
Any suggestions on what I might be doing wrong ?
The -cpp_out tag specifies the output directory for generated c source code.
I would suggest trying (if proto is actually stored under the c: directory c:\addressbook.proto)
protoc c:\addressbook.proto --cpp_out=./
or
protoc addressbook.proto --cpp_out=./
Since the only answer in this thread didn't lead me to the solution I needed, here it is.
The syntax for calling the protoc.exe is as follows:
protoc --proto_path=<proto_directory> --cpp_out=<output_directory> <proto_file>
Important is that the argument to proto_path is a directory instead the specific .proto-file path. The actual proto files used are appended at the end of the command (<proto_file>).
Related
I recently finished the basic tutorial for C++ here and wanted to set up a project based on the proto files from here. I followed a similar directory structure as the tutorial and changed up the CMakeLists.txt file to accommodate the new files.
I'm currently trying to just compile the manager.proto file. I was able to compile the file and get my server/client files, however the files are being outputted within cmake/build/minknow_api rather than the expected cmake/build folder. This meant the make command would return the error:
clang: error: no such file or directory: '/Users/name/Documents/grpc/examples/cpp/minknow_api/cmake/build/manager.grpc.pb.cc'
clang: error: no input files
I read that it was because protoc outputs based on the imports of the proto file, i.e the file comes with import minknow_api/device.proto for instance. I copied the files from within the cmake/build/minknow_api into cmake/build/ and reran make and it seemed to work, however, the C++ file imports as expected are searching within a minknow_api directory, meaning I'd have to manually edit these imports to look within the current directory instead of to then compile successfully.
I've tried experimenting with trying to get rid of the minknow_api from the proto imports, however had no luck and only got more import issues during compilation. It seems some files have the same names for messages etc, which means I had to keep the minknow.somename as the package so I can thus distinguish in the files which imported values I wanted to access. I've also tried moving files into their own directories like instance.proto which has package minknow.instance would go inside of instance directory, but still no luck.
I was wondering if anyone could figure out how to get rid of the minknow_api out of my proto imports properly so that I won't get these import and output directory issues down the track?
I'm following the instructions on github.com/jcjohnson/torch-rnn and have it working until the training section. When I use th train.lua -input_h5 my_data.h5 -input_json my_data.jsonI get the error Error: unable to locate HDF5 header file at /usr/local/Cellar/hdf5/1.10.0-patch1/include;/usr/include;/usr/local/opt/szip/include/hdf5.h
I'm new to luarocks and torch, so I'm not sure what's wrong. I installed torch-hd5f. Any advice would be very much appreciated.
Check that the header file exists and that you have the correct path.
If the header file is missing you skipped the preprocess step. If the header file exists it's likely in your data directory and not in the same directory as the sample.lua code:
th train.lua -input_h5 data/my_data.h5 -input_json data/my_data.json
When I compile my c++ program that uses Protobuf, and then run the linux strings command on the binary, one of the strings is a path to the generated cc file, with my home directory and everything. Obviously I'd like to eliminate my home directory and other personal information from the binary.
Where does this path come from and how can I prevent it from making it into the compiled binary?
The string comes from the embedded protobuf descriptor, which is used to perform dynamic introspection of protobuf types. Essentially, the descriptor describes your whole .proto file. The descriptor itself is encoded in protobuf format; see google/protobuf/descriptor.proto.
Now, the descriptor normally should not contain absolute paths like you describe. It really wants to contain "canonical" paths -- that is, the path name of the proto file relative to the source code root, or in other words, the path that you'd write in an import statement for that file. For instance, descriptor.proto's own canonical path is google/protobuf/descirptor.proto; to import it, you would write import "google/protobuf/descriptor.proto";.
The reason your descriptors are getting the full absolute filesystem path is because that is the path that you are passing to protoc, and you are not passing a -I flag to tell protoc where the root of your source tree is. Since protoc can't figure out the root of the source code, it is falling back to the file system root.
For instance, say your .proto file is /home/foo/myproj/src/frobber/baz.proto. Say that the src directory in this path is your "source root", meaning that you want people to write import "frobber/baz.proto"; to import your proto file. In that case, you want to invoke protoc like this:
protoc -I/home/foo/myproj/src /home/foo/myproj/src/frobber/baz.proto
Note that if you are running the command from, say, the myproj directory, then you probably shouldn't specify an absolute path at all:
protoc -Isrc src/frobber/baz.proto
It is very important that the -I flag here is a textual prefix of the source file name. protoc is dumb and only knows how to compare strings. It doesn't, for instance, know what the current directory is:
# DOES NOT WORK
cd /home/foo/myproj
protoc -I/home/foo/myproj/src src/frobber/baz.proto
And it also cannot canonicalize "..":
# DOES NOT WORK: protoc doesn't collapse "xyz/../".
protoc -Isrc xyz/../src/frobber/baz.proto
However ".." is OK if it's consistent, because again protoc only cares about a prefix match:
# OK: Prefix is consistent.
protoc -Ixyz/../src xyz/../src/frobber/baz.proto
If you'd rather not have a descriptor
You can compile your proto files in "lite mode" by placing the following line in your .proto file:
option optimize_for = LITE_RUNTIME;
In this mode, descriptors will not be included at all. Additionally, you can link against the "lite" version of the protobuf runtime library, which is much smaller than the regular version. However, many useful features will be disabled. The whole reflection interface will be gone, and anything that depends on reflection will be gone as well. For example, TextFormat, which is what the DebugString() method uses to convert messages into text to print for debugging, will be removed, therefore debugging will be harder.
I am trying to use a resource file (*.rc) in a command line compiled application, using a make file. I discovered that even though the current directory was the output directory, and that cl seems to be building its object files to this output directory, that the rc compiler will only put its output .res file in the same location as the .rc file. How can I, with some flexibility, tell rc to put its output file in a different location without a manual 'move' operation?
i.e.:
This will put source.obj file in the (current) c:\foo\bar\ directory:
c:\foo\bar>cl c:\foo\src\source.cpp
Whereas this will put a .res file in the c:\foo\res\ directory:
c:\foo\bar>rc c:\foo\res\resource.rc
The main problem is it is awkward to find a way to have the make file script do the post-compile move of the res file. Is there a way to change the output folder?
Probably an answer to your question:
MSDN specs for RC
This is the NMAKE line I have for resource compiler:
$(RC) -fo$# $**
It puts the resource file where I direct it.
It seems, however, that the directory has to exist beforehand, or RC throws its hands up in the air in dismay. Maybe I've misunderstood this problem, but I'm right about that, it's pretty lame behavior. And in that case, depending on the order of execution, you may need a MKDIR command in your makefile.
I don't quite understand the path in protobuf. My file layout like this:
Top
A
a.proto
B
C
c.proto // import "A/a.proto";
I have written an RPC system based on protobuf and I need generate two kinds of files(client and server code) from c.proto. Client code should be placed in B and Server code still in C.
I can't write a correct command.
Top> protoc -I=. --client_out=./B/ C/c.proto will generate client code in B/C and the #include in code will have a wrong path.
Top/C> protoc -I=../ -I=./ --client_out=./ ./c.proto lead a protobuf_AddDesc_* error.
For every .proto file, protoc tries to determine the file's "canonical name" -- a name which distinguishes it from any other .proto file that may ever find its way into your system. In fact, ideally, the canonical name is different from every other .proto file in the world. The canonical name is the name you use when you import the .proto file from another .proto file. It is also used to decide where to output the generated files and what #includes to generate.
For .proto files specified on the command line, protoc determines the canonical name by trying to figure out what name you would use to import that file. So, it goes through the import paths (specified with -I) and looks for one that is a prefix of the file name. It then removes that prefix to determine the canonical name.
In your case, if you specify -I=. C/c.proto, then the canonical name is C/c.proto. If you specified -I=C C/c.proto, the canonical name would then simply be c.proto.
It is important that any file which attempts to import your .proto file imports it using exactly the canonical name determined when the file itself was compiled. Otherwise, you get the linker error regarding AddDesc.
In general, everything works well if you designate some directory to be the "root" of your source tree, and all of your code lives in a subdirectory of that with a unique name designating your project. Your "root" directory should be the directory you pass to both -I and --client_out. Alternatively, you can have separate directories for source files vs. generated files, but the generated files directory should have an internal structure that mirrors your source directory. You can then specify the generated files directory to --client_out, and when you run the C++ compiler, specify both the source and generated files directories in the include path.
If you have some other setup -- e.g. one where the .proto files live at a different canonical path from the .pb.h files -- then unfortunately you will have some trouble making protoc do what you want. Though, given that you are writing a custom code generator, you could invent whatever rules you want for the way its output files are organized, but straying from the rules the standard code generator follows might lead to lots of little pitfalls.