Thanks so much for fixing the message. And your point about symlinks is also
very well taken. Amazing how hard it is to just canonicalize a path! Keep up
the amazing work. The Java mobile-optimized version is soo much faster to
initialize - thanks!
Artem

On Wed, Oct 7, 2009 at 5:42 PM, Kenton Varda <ken...@google.com> wrote:

> I've updated the error message in rev 233.
> The symlink issue is a serious one.  If we simply used realpath() to
> canonicalize paths then it would essentially prevent people from using any
> symlinks at all in their source tree, which I think in an unacceptable
> limitation.  Lots of unix users take advantage of symlinks in their build
> systems -- google included.
>
>
> On Tue, Oct 6, 2009 at 12:37 PM, Artem Petakov <p.ar...@gmail.com> wrote:
>
>> 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:
>> "D:\Artem\wsl-trunk\wsl_root\src\com\wsl\CardioTrainer\weightloss\weightloss.proto:
>> 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.
>> http://www.google.com/codesearch/p?hl=en&sa=N&cd=1&ct=rc#yJqH5U7qc7c/subversion-1.4.0/subversion/libsvn_subr/path.c&q=svn_path_canonicalize&l=63
>>
>> // 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,
>> Artem
>>
>> 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 
protobuf+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/protobuf?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to