[antlr-interest] PreservingFileWriter

Ric Klaren klaren at cs.utwente.nl
Tue Jun 11 05:02:16 PDT 2002


Hi,

On Tue, Jun 11, 2002 at 04:19:40AM -0700, Bogdan Mitu wrote:
> One question: isn't this feature slowing down things? I understand your
> point in avoiding recompilation, but this can be accomplished in other ways
> too (<shameless-advertisement> for instance, using my new Ant task
> </shameless-advertisement>). Can you please consider making this feature
> optional (through a command-line parameter)?

Uhm ever tried to suggest command-line parameter to Terence? <ducks-for-cover>

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 ;) ) 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, and
above all I don't want to install java just to run 'make', for me it was
already a big step to install java to run antlr =)</RANT>).

I discussed a bit about this feature with Terence I probably suggested
commandline stuff somewhere in that discussion (and miraculously walked
away with my head still attached to my shoulders ;) ). 

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)

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/ 



More information about the antlr-interest mailing list