[antlr-interest] PreservingFileWriter

[Bogdan Mitu]

--- Ric Klaren <klaren at cs.utwente.nl> wrote:
> I don't quite see how ant can help recompilation problems in C++ projects
> (behaves slightly different than java with the source and header files).
> Does ant look at the contents of files? Unless I missed something when I
> looked at it (<RANT TYPE="plz ignore ;)"> and hated it on sight, I don't
> quite see the use of ant (mostly in C/C++ settting, for java it might be
> way cool ;) ) 

I don't know much about C++ (<RETURN-RANT> more precisely, I don't want to
remember </RETURN-RANT>), so I speak only for Java environments. My Ant task
is looking at the imported token files and at the generated files, and only
if dates are wrong, it invokes ANTLR again. So it avoids all unnecessary
recompilation, except for cases when you add a whitespace in the grammar. It
also save time by not invoking ANTLR at all, when it's not necessary.

By the way, you can do the same in PreservingFileWriter; you have all
information required about supergrammars, imported files and generated files
collected during grammar analysis by ANTLR.

> Makefile's allow me to do things in a very flexible way and
> I
> for as far as Makefile syntax can be cryptic it certainly beats XML

Just incidentally, the next incarnation of Ant (Ant 2) will be independent
of XML or other particular encoding, which I think it's a step in the right
direction.

...
> If I look at compilation times then running antlr is probably less than 1%
> of the time to compile the generated files (and without minimal remakes,
> this probably will go into the 0.001% (okay I may be exagerating here..
> but
> it means that I would get lethal doses of caffeine)). My educated guess is
> that in very few projects antlr's runtime is the biggest factor. So I'm
> inclined to keep this thing the default. (if someone provides a 'clean'
> patch I would not dream of objecting though)

You are probably right about times, it's more a psychological factor (<RANT>
against improvements that make things slower </RANT>). And it's my inability
to get grammars right from the first time that makes me ANTLR them several
times before having something to compile ;-) Or maybe it's because those
damned temporary files were making the Ant unit tests to fail from time to
time, and it took us two days to figure what's happening :-))

Anyway, I can live with it as default behavior.

Cheers,
Bogdan

> Another option is extending the interface of Tool.java to select a
> different output style (preserving/nonpreserving) for the openOutputFile
> method. But I'm not 100% sure how this interacts with antlr's preprocessor
> (tokenfiles are also part of the dependency tree). I looked a bit closer
> and probably we should move the openOutputFile stuff to the codegenerators
> where they can select the preferred PrintWriter, then have Tool.openoutput
> file proxy on that method? Something along those lines at least.
> 
> Cheers,
> 
> Ric
> --
>
-----+++++*****************************************************+++++++++-------
>     ---- Ric Klaren ----- klaren at cs.utwente.nl ----- +31 53 4893722  ----
>
-----+++++*****************************************************+++++++++-------
>      Human beings, who are almost unique in having the ability to learn
>    from the experience of others, are also remarkable for their apparent
>          disinclination to do so. --- Douglas Adams, Last Chance to See
> 
> 
>  
> 
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ 
> 
> 
> 


__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com

 

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/