[GRASS5] PATCH: sql expression parser

Glynn Clements glynn at gclements.plus.com
Mon Jun 13 04:51:59 EDT 2005


Daniel Calvelo Aros wrote:

> [Glynn] 
> > That's a bad idea, IMHO.
> >
> > Either developers will forget to commit them when lex.l or yac.y
> > change, or they will end up being committed when lex.l or yac.y
> > haven't changed (due to different lex/yacc programs generating subtly
> > different code). Also, CVS doesn't deal with timestamps correctly, so
> > there can be version skew issues.
> 
> Well, on the one hand, the files hadn't been touched since circa 2001.

"cvs log" says otherwise.

They were created on 2001/05/10, and have been each been modified
around 20 times between then and when I last modified them on
2004/09/09 (to add IS NULL/NOT NULL support).

Furthermore, even if lex.l/yac.y were never changed, the generated C
files (lex.yy.c, y.tab.c, y.tab.h) will typically differ between
developers, so "cvs commit lib/db/sqlp" would typically end up
committing the local copy.

> > It would be better to just ensure that all lex/yacc files can be
> > processed by any version of these tools. It shouldn't be that hard; 
> > we aren't doing anything particularly complex with lex/yacc.
> 
> On the other hand, having a "portable" input feels more correct. What needs to
> be done in order to fix that? Linux, MacOSX (because of GNU, I believe) work
> Ok. We spotted problems with solaris, and so far they are minor.  Whitespace
> is no issue. Let's just make solaris happy. Comments are more important, IMHO.
> Paul, could you try moving the comments within the "C" part of the code?

Neither of those files is complex enough to need comments.

Try putting comments inside %{ and %}, but if that doesn't work, just
get rid of them.

-- 
Glynn Clements <glynn at gclements.plus.com>




More information about the grass-dev mailing list