Hi Kenton,
Thanks for the reply and for your amazing & tireless work on this library --
it's invaluable.

What you point out  is exactly the problem -- the ANT Fileset tag generates
a fully qualified path for the protocol buffers themselves, and so I have to
also fully qualify my "proto_path" as well to make it match. I can certainly
appreciate that it's hard to make the canonical paths work, but it does
strike me as non-intuitive -- I'm so used to being able to give any path to
a tool. If it's too hard, perhaps at least a warning to this effect in that
proto_path error message would help save future users time?

Right now the error it gives is:
File does not reside within any path specified using --proto_path (or -I).
 You must specify a --proto_path which encompasses this file."

Perhaps add: "Make sure the proto_path is an exact prefix of the file path
to the protocol buffer."

Hmm, I see your TODOs as well (in importer.cc), although the objection to
realpath strikes me as somewhat less serious than the common error I am
facing now. Your call of course. SVN has something for canonicalizing, but
it's not super-pretty.

// TODO(kenton):  It would be nice to handle "..", e.g. so that we can
figure//   out that "foo/bar.proto" is inside "baz/../foo".  However,
if baz is a//   symlink or doesn't exist, then things get complicated,
and we can't//   actually determine this without investigating the
filesystem, probably//   in non-portable ways.  So, we punt.////
TODO(kenton):  It would be nice to use realpath() here except that
it//   resolves symbolic links.  This could cause problems if people
place//   symbolic links in their source tree.  For example, if you
executed://     protoc --proto_path=foo foo/bar/baz.proto//   then if
foo/bar is a symbolic link, foo/bar/baz.proto will canonicalize//   to
a path which does not appear to be under foo, and thus the compiler//
 will complain that baz.proto is not inside the --proto_path.

Thanks for the help,

On Tue, Oct 6, 2009 at 2:45 PM, Kenton Varda <ken...@google.com> wrote:

> What is your exact protoc command line?
> I see this in your XML:
>   protoc --proto_path=./src --java_out=./src
> src/com/wsl/CardioTrainer/track/*.proto
> This may unfortunately confuse protoc, as it doesn't know that "src/" and
> "./src/" mean the same thing.  Canonicalizing paths is surprisingly hard
> (especially when trying to be portable), so protoc looks for exact matches.
>  This would work better:
>   protoc --proto_path=./src --java_out=./src
> ./src/com/wsl/CardioTrainer/track/*.proto
> Or this:
>   protoc --proto_path=src --java_out=./src
> src/com/wsl/CardioTrainer/track/*.proto
> On Tue, Oct 6, 2009 at 8:58 AM, Artem <p.ar...@gmail.com> wrote:
>> Hi there,
>> We're a long-time user of Java protobuffs. Just upgraded to 2.2.0 to
>> experience the power of LITE_RUNTIME. Everything is rocking and
>> working much faster, except for one annoying problem.
>> If I use anything but a processed full path for the --proto_path
>> argument, it does not work. In other words, if I use for example $
>> {basedir}../.. it does not work, meaning it does not understand to
>> convert the ../.. to lower directories.
>> Is this expected behavior? I was able to work around it by having ANT
>> process the paths (I am no ANT expert so apologies for the below):
>>  <property name="WSL_ROOT" value="../.." />
>>  <path id="WSL_ROOT_PATH" path="${basedir}/${WSL_ROOT}"/>
>>  <property name="WSL_ROOT_ABSOLUTE" value="$
>> {toString:WSL_ROOT_PATH}" />
>>  <target name="protoc-trackproto">
>>    <echo>Execute: protoc --proto_path=./src --java_out=./src src/com/
>> wsl/CardioTrainer/track/*.proto</echo>
>>    <apply executable="${full-protoc-command}" failonerror="true" >
>>      <arg value="--proto_path=${WSL_ROOT_ABSOLUTE}/src/com/wsl/
>> CardioTrainer/track" />
>>      <arg value="--java_out=${WSL_ROOT}/src" />
>>      <fileset dir="${WSL_ROOT}/src/com/wsl/CardioTrainer/track">
>>        <include name="*.proto"/>
>>      </fileset>
>>    </apply>
>>  </target>
>> Thanks,
>> Artem
>> >>

You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To post to this group, send email to protobuf@googlegroups.com
To unsubscribe from this group, send email to 
For more options, visit this group at 

Reply via email to