[antlr-interest] org.antlr.Tool outputs to wrong directory on Windows in antlr-3.1.3

[Martin Probst]

So, should I file a bug, or what? We can reproduce the broken
behaviour on three different Windows machines - something must have
changed from 3.1.2 to 3.1.3 that breaks this.

Martin

On Fri, Apr 3, 2009 at 16:35, Jim Idle <jimi at temporal-wave.com> wrote:
> Martin Probst wrote:
>>
>> Hi,
>>
>> this may sound weird, but we're running into a problem with our build
>> system since we upgraded from antlr-3.1.2 to antlr-3.1.3, and it only
>> happens on Windows (so we only have 30% unhappy developers now, but
>> still ;-)).
>>
>> What happens is that if you run (and this is what our build effectively
>> does):
>> mkdir –p ../../tmp/com/xhive/xquery/parser
>> java -classpath ../../lib/misc/antlr-3.1.3.jar org.antlr.Tool -o
>> ../../tmp/ com/xhive/xquery/parser/XQueryParser.g -lib
>> ../../tmp/com/xhive/xquery/parser
>> com/xhive/xquery/parser/XQueryTreeParser.g
>>
>> This will on Mac OS X and on Linux boxes create XQueryParser.java in
>> ../../tmp/com/xhive/xquery/parser, and this is what we expect.
>>
>
> Yes, it should do that.
>>
>> Running this with antlr-3.1.3 on Windows will create XQueryParser.java
>> in ../../tmp, without the package paths. I'm pretty sure that this is
>> a regression from antlr-3.1.2 where it didn't happen.
>>
>
> Yes, it would be. However, as far as I can tell, the only reason it would do
> this on Windows is if the JRE does not make File() work in the same way as
> on UNIX, or of there is a hard coded directory separator (which there isn't
> I think), or that the ../ relative path isn't working correctly (this seems
> most likely).
>>
>> Now we can fix this by specifying the full path as the output
>> directory ("-o ../../tmp/com/xhive/xquery/parser"), but that seems
>> unelegant, and also I'd like to know what the expected behaviour
>> should be.
>>
>
> As per your experience with UNIX.
>
> Jim
>