[antlr-interest] Change in output location with 3.0b7

[Jim Idle]

Ter,

We had some discussions of this and you made a second option that would
always ignore subdirectories, intending that the -o option would mirror
the input directories. It could be that you did it the other way around
etc.

however, I needed this because Visual Studio build rules can't cope with
making the subdirectories in the output. Hence I think that we already
have what we need (was the option -od or something?).

Jim

-----Original Message-----
From: antlr-interest-bounces at antlr.org
[mailto:antlr-interest-bounces at antlr.org] On Behalf Of Terence Parr
Sent: Monday, April 16, 2007 12:10 PM
To: ANTLR Interest
Subject: Re: [antlr-interest] Change in output location with 3.0b7


On Apr 16, 2007, at 8:58 AM, Martin Fowler wrote:

> I've just upgraded to 3.0b7 and I noticed a change in where Antlr  
> puts its output files (didn't spot it in the update log.)

Hi Martin. :)

Sorry 'bout that.  I was futzing with that stuff to build the -depend  
option, which prints all the dependencies.

> Previously if you specified an output directory with -o and you had  
> a grammar in a subdirectory it would put the output in the  
> corresponding subdirectory in the output directory. Now it just  
> puts it directly in the subdirectory. I'm not saying this is wrong,  
> but I thought I'd point it out as it's caused my stuff to break :-(

Ah.  Ok, so

$ java org.antlr.Tool -o /tmp T.g

generates /tmp/TParser.java and so does:

$ java org.antlr.Tool -o /tmp subdir/T.g

rather than /tmp/subdir/TParser

What do people think?  I sort of like the idea that I can force  
output to a specific directory.

Can you get away with being explicit like this?

$ java org.antlr.Tool -o /tmp/subdir subdir/T.g

> I've been intending to write a little program to walk my src  
> directory and use the API to generate output files if necessary in  
> a corresponding gen directory (which I can keep out of version  
> control). (I have a lot of them as I'm exploring lots of  
> alternative langauges and parsers within the same project). If  
> nothing else I guess this makes me want to do it. But if there's an  
> easier way to do this or someone's already done it do let me know ;-)

Can the BuildDependencyGenerator.java class help you or -depend?

Thanks,
Ter