Issue 247 in protobuf: Ability to redirect file output to stdout
prot...@googlecode.com
Owner: ken...@google.com
Labels: Type-Defect Priority-Medium
New issue 247 by compuwarescc: Ability to redirect file output to stdout
http://code.google.com/p/protobuf/issues/detail?id=247
Unable to output source to stdout.
Being able to receive output to stdout rather than just as files should (i
would think) be a rather simple flag to add to protoc and would improve the
ability to use protoc at run time for dynamic code generation.
i.e.
It would be nice to be able to call
protoc --java_out X.proto
and receive the source on stdout.
prot...@googlecode.com
Comment #1 on issue 247 by moofish32: Ability to redirect file output to
stdout
http://code.google.com/p/protobuf/issues/detail?id=247
I think this would be a very beneficial enhancement for the same reason.
Solves any concerns over permissions in the unix environment.
prot...@googlecode.com
Comment #2 on issue 247 by ken...@google.com: Ability to redirect file
http://code.google.com/p/protobuf/issues/detail?id=247
What happens if multiple files are generated? For example, if you
have "option java_multiple_files = true;" in your .proto file. This seems
like it could get weird.
prot...@googlecode.com
Comment #3 on issue 247 by compuwarescc: Ability to redirect file output to
stdout
http://code.google.com/p/protobuf/issues/detail?id=247
To be honest I had not considered that scenario. Perhaps breaking this
into two feature requests would be more appropriate...
1) Command line flag to output to a source archive (zip / jar /
tar) "--archive=zip"
( Similar in form to a standard "source archive" where java source
files are where their compiled classes would normally be in the jar file.
-- noting, of course, that a jar file is really just a zip file and that
this feature would require some implementation of assembling zip files
being included in protoc )
2) Command line flag to stream the contents of the archive to stdout,
which would imply or require that the flag to output to an archive was
set. "--stdout"
This solution is a bit more complicated but should work for multiple
languages and does not affect the potential contents of the file like a
reserved delimiter would. For java, the classes provided with the JRE
JarInputStream, ZipInputStream, etc... can be used to read this input
easily from stdout.
prot...@googlecode.com
Status: Accepted
Labels: -Type-Defect Type-Enhancement
Comment #4 on issue 247 by ken...@google.com: Ability to redirect file
output to stdout
http://code.google.com/p/protobuf/issues/detail?id=247
We do already have the ability to output to a jar file. I suppose dumping
the jar to stdout would not be so bad. Might not make it into the upcoming
release, though.
prot...@googlecode.com
Comment #5 on issue 247 by compuwarescc: Ability to redirect file output to
stdout
http://code.google.com/p/protobuf/issues/detail?id=247
After further use, I think it's also (and possible more) important to
stream the output of the -o tag (a FileDescriptorProto buffer) to stdout.
If this gets implemented I would hope support for the -o flag would be
included.
prot...@googlecode.com
Comment #6 on issue 247 by ken...@google.com: Ability to redirect file
http://code.google.com/p/protobuf/issues/detail?id=247
For -o, you can do:
protoc my.proto -o/dev/stdout
This just doesn't work with --java_out (or whatever lanugage) because it
would interpret /dev/stdout to be a directory and would try to create files
inside it, which would fail.
prot...@googlecode.com
Comment #7 on issue 247 by compuwarescc: Ability to redirect file output to
stdout
http://code.google.com/p/protobuf/issues/detail?id=247
Seems to me that will only work on linux where /dev/stdout is a file
pointer to stdout.
Do you know of any way to do this on a windows platform?
prot...@googlecode.com
Comment #8 on issue 247 by mike.wel...@gmail.com: Ability to redirect file
http://code.google.com/p/protobuf/issues/detail?id=247
You're also forgetting the C++/C world where each code generation will
output at least 2 files, a .cpp and a .h. So you would pretty much have to
output in some sort of standard tar/jar container format for this to work
nicely.
prot...@googlecode.com
Comment #9 on issue 247 by compuwarescc: Ability to redirect file output to
stdout
http://code.google.com/p/protobuf/issues/detail?id=247
I've been thinking a lot of the use of run-time usage of .proto files in
java (I use this technique) and I've gone through two uses now - both
involve invoking protoc from java and then using the output. The first was
to perform actual code generation, compile, and load. The second (and
better i think) was to use the FileDescriptorSet output and load that into
FileDescriptor(s).
The primary limitation of both approaches was the need to
1) invoke protoc through the "shell" (not very platform independent)
2) manipulate files when everything could/should be done in memory
The more I think on it, the more I think taking the "this is an advanced
use of protobuf" approach and saying the most flexible solution to users
that want to do this kind of work is to provide a java version of the
current C library used to translate between ".proto" files
and "FileDescriptorProto" protobufs.
This is the one big piece missing from the run-time java capability,
everything but going .proto <=> FileDescriptorProto is in there already.
I'm interested in what Kenton or other active developers of the library
think about this - how difficult would it be to port the C code to java?
how much of a maintenance problem would this make? I would be willing to
assist with this effort if it is thought a useful contribution to the java
library. If it is believed this is a worthwhile pursuit, I believe that
would supersede the need for console output from protoc.
prot...@googlecode.com
Comment #11 on issue 247 by compuwar...@gmail.com: Ability to redirect file
http://code.google.com/p/protobuf/issues/detail?id=247
Shall I create a new issue to track "java parser" so it can have it's own
fair discussion instead of being buried in this issue?
prot...@googlecode.com
Comment #12 on issue 247 by ken...@google.com: Ability to redirect file
http://code.google.com/p/protobuf/issues/detail?id=247
Sure.
prot...@googlecode.com
Comment #10 on issue 247 by ken...@google.com: Ability to redirect file
http://code.google.com/p/protobuf/issues/detail?id=247
The C++ parser and descriptor validation code is a lot more complicated
than you might imagine. The most difficult part is custom options: a
custom option can be used in the same file where it is defined -- even
before or *inside of* its own definition.
So, porting would be difficult, and likely buggy. Moreover, keeping the
code in sync with the C++ parser would be annoying.
On the other hand, it would be very easy to write a comprehensive test --
just parse all the unit test .proto files using both the C++ and Java
parsers and verify that identical DescriptorProtos come out.
After years of arguing against a Java port of the parser, I am starting to
think that it may be time to give in... Even inside Google we have a hard
time stopping Java users from writing their own .proto parsers (which are
almost always broken).
prot...@googlecode.com
Comment #13 on issue 247 by compuwar...@gmail.com: Ability to redirect file
http://code.google.com/p/protobuf/issues/detail?id=247
Discussion for implementing Java Parser moved to Issue 263
prot...@googlecode.com
prot...@googlecode.com
Status: WontFix
Comment #16 on issue 247 by xiaof...@google.com: Ability to redirect file
output to stdout
https://code.google.com/p/protobuf/issues/detail?id=247
(No comment was entered for this change.)
--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings