[antlr-interest] Antlr ANT task: Seemless builds using the Antlr -Problems and solutions. Help appreciated!

[M C]

Hi Scott,

Thanks for your quick and detailed response. First of
all kudos to you for working the ANT task and the cool
eclipse plugin. Good build and IDE support are very
necessary but sadly often overlooked in open source
projects. Great this is not the case for Antlr!

I have some comments to your mail below:

(*) Looking forward for the update. Was afraid the
plugin project was lost. I hope it will suport eclipse
3.1M6+

 --- Scott Stanchfield <scott at javadude.com> skrev: 
> I'm working on updating the ANTLR ANT task ;)
> 
> *However*, order of .g compilation can matter, as
> one grammar can output
> token types that another grammar needs, or there
> could be grammar
> inheritance.

Point taken. Maybe this would only be recommended in
case compilation order does NOT matter. (Unless antlr
is changed to process the *.g files in multiple passes
which is probably too much implementation work
compared to the benefit).

> javac doesn't have this problem b/c the compiler
> reads "all" the java files
> and compiles them as a group. ANTLR only processes a
> single file at a time. 

My ANT script does this be calling the ANTLR task
multiple times. However this is very complicated and
requires the exstra ant-contrib library. Would prefer
something that is simple and that I can use with a
standard ANT 1.6.2+ installlation.
 
> I was planning on checking mod times and adding the
> new options (-smap and
> -plugin [for xml support]).

Great!
 
> For each of your requests:
> * mutiple .g files -- ANTLR itself doesn't support
> it
>   I could probably do this, with the cavaet that
> order can bite you

That would be fine!

> * mapping source->dest paths - hmm... the task could
> do that...
>   ANTLR itself doesn't "know" the package; it's just
> part of the header spec
>   I'll look into this... I'd really like this
> meself...

Would be really nice. It was VERY hard to do this in
my ANT script and I am not sure it works on all
platforms.
 
> * timestamps -- I want to add this to the task

Again, super. I look forward to that. It will speed up
build times a lot (by removing all the unnecessary
cascade builds).
 
> * invoking twice for docs/java -- ANTLR runs with
> separate
>   generators for each. We should be able to write a
> combo generator
>   that we delegate to both java and docbook or html
> generators...
>   Hmmm... If I have time, I'll take a quick poke at
> this, but
>   it's not likely I'll have time...

Yea nice, but least important. I can invoke the task
twice.

> I'd also like to set up some way to make "clean"
> easy, so we'll know which
> files were generated by antlr. I'm doing this in the
> eclipse plugin (I added
> "clean" support), but to do it for an ant build
> would require tracking
> generated files in another file, like
> .antlr-generated or something. We can
> then have a <antlr clean="yes"> option that removes
> any generated files. (We
> would have to always append to the .antlr-generated
> file to capture all
> renames and such until a clean)

Not sure that I understand this. Can't the files that
was generated be derived by looking at the *.g files
and the arguments to the ANT task (assuming these do
not change)? I generate java files to a special
build\generatedsrc directory. I have no problem
cleaning that. As a matter of fact I am not sure I
like to have additional files generated to keep track
of things if it can be avoided.
  
> I'm working on the ant task today, btw, so good
> timing ;)

Luck I guess. I am very, very glad you are working on
this 

:-)

 Then I've got to
> figure out how to contribute the changes... too much
> fun...

> Thoughts?

Hope the comments are useful for you.

Cheers,
Morten