[antlr-interest] 3.1.3 only accepts *.g extensions

Gary R. Van Sickle g.r.vansickle at att.net
Wed Mar 25 23:19:53 PDT 2009


> From: William H. Schultz
> 
> On Mar 25, 2009, at 12:07 PM, Jim Idle wrote:
> 
> > Gavin Lambert wrote:
> >> At 04:16 26/03/2009, Jim Idle wrote:
> >>> That is indeed a bug, though since we changed some 
> internals, there 
> >>> is no real need not to use .g any more too be honest. I 
> changed the 
> >>> VS rules files some time ago. I will take a look at this 
> as it must 
> >>> be an oversight (probably on my part when I changed 
> things for the 
> >>> Maven plugin).
> >>
> >> I thought that one of the reasons for the alternate extensions was 
> >> that the VS rule files (among other things) needed the 
> extension in 
> >> order to work out which output files would be produced 
> from a given 
> >> grammar file (which in turn lets it know whether it needs to 
> >> recompile or not).  Isn't that still the case?
> >>
> > No - I changed the rules files so that they work off the different 
> > extensions or can be assigned to any .g file. There are more rules 
> > files and you can right click and assign the type 
> accordingly in the 
> > project explorer. Still, it should be supporting other extensions 
> > though. must have been hard coded somewhere by accident.
> 
> Maybe that's a solution for Visual Studio, but it's not a 
> solution for Xcode.  Custom build rules are done on a 
> per-target basis (which sucks, I'll admit), you have to 
> specify an expression to match the filename, you provide a 
> script to do the work, and you specify output files.
> 

Similar issue with bog-standard makefiles.  Though like anything else there
are workarounds, it makes things at least an order of magnitude easier if
you know a priori that files "nameLexer.h nameParser.c name.tokens etc etc"
come from "name.g<whatever the combined extension is>", but just name.{c,h}
come out of "name.g<whatever for trees>".

-- 
Gary R. Van Sickle



More information about the antlr-interest mailing list