[antlr-interest] Re: [antlr-dev] ANT build cruft?

[Matt Benson]

--- Martin Probst <mail at martin-probst.com> wrote:

> Hi,
> 
> > - The new task addresses the shortcomings of the
> > existing apache-hosted task.  I don't remember
> what
> > they are actually; having gotten frustrated with
> that
> > task many years ago I have actually used <java
> > class="antlr.Tool"> or the commandline since.  Can
> any
> > current users offer input here (except for that
> silly
> > "ANTLR task should create its own output dir"
> stuff).
> 
> The problem is dependency management and time
> stamps. To ANT it looks  
> like ANTLR has one input file, foo.g, and
> potentially several output  
> files, fooLexer.java, FooParser.java, etc. Now if I
> change the  
> grammar, ANT thinks it needs to update all three
> files. But when it  
> runs ANTLR, ANTLR only updates the files it really
> has to. So there  
> can be changes which actually don't change anything
> in the files, and  
> changes which only change some of the files. In any
> of these, ANT  
> keeps running the ANTLR task every time because it
> doesn't expect  
> this behaviour.
> 
> For C++ people this careful behaviour about
> modifying/touching files  
> might actually be very nice (less C++ compiling),
> but for Java it's  
> generally a lot more annoying to have ANTLR running
> every time than  
> compiling two Java files once more than absolutely
> necessary. I think  
> anyone with a real build system uses the old "touch
> file" strategy,  
> which actually results in an optimal solution.
> However I think a  
> built-in task can hardly start creating magic
> "touch" files, so it  
> should maybe resort to saying: "one of the output
> files is newer than  
> the grammar" instead of "all of the output files are
> newer than the  
> grammar", if that's possible in ANT?

I am 99% sure that is doable using existing features;
if not it would be trivial.  It still remains that it
would be nice to have a uniform way of knowing what
those target files are.  If this could be accessed via
some forthcoming ANTLR API we could wrap that up into
an Ant file mapper (these can have multiple outputs
for a given input).  The API is IMO necessary due to
ANTLR's myriad implementation languages.

-Matt

> 
> Martin
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com