[antlr-interest] file names and grammar names

[Don Caton]

Micheal:

> Not quite the same. And not standard at all. Foo.cpp may 
> actually contain types NotFoo<T> and SomethingElse. Same with 
> Foo.cs, Foo.C, Foo.py etc

I typed that message too fast, what I meant was standard behavior as far as
the naming of output files is concerned, which generally doesn't have
anything to do with the actual contents of the file.

Perhaps using cpp files wasn't a good analogy.  What I was trying to say is
that if you have a grammar in fooParser.g then (IMO) it is reasonable to
emit fooParser.hpp and fooParser.cpp as defaults (or .cs, .py or whatever is
appropriate for the target language).  That makes things much simpler as far
as build systems go, and you can override the output names if you want.

> > And even if foo.g hasn't changed, the timestamps of the 
> output files 
> > should be guaranteed to be later than foo.g.
> 
> You mean due to a previous build right?. Not suggesting the 
> outputfiles be touched always?

Yes.  If you run antlr against any given input, every output file should be
touched (assuming no errors occur).  I'm not sure why Antlr tries to be
clever about not updating output files that don't need to change, but it
ends up requiring workarounds to prevent unnecessary rebuilding in any
system that uses timestamps to figure out what's out of date.

> Making it an option is more user-friendly than my previous 
> API/library suggestion. Not as flexible mind but...

The API/library idea isn't bad, but then you need an implementation for all
the different platforms someone might run Antlr on.  Probably better if
that's in the tool itself.

Don