[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