[GRASS5] Re: [GRASS-COMMIT-CVS] CVS update:grass/src/raster/r.binfer

[David D Gray]

Markus Neteler wrote:
> 
> On Wed, Nov 15, 2000 at 08:09:40PM +0000, David D Gray wrote:
> [...]
> > > > Author:       david
> > > >
> > > > Update of /grassrepository/grass/src/raster/r.binfer
> > > > In directory intevation.de:/tmp/cvs-serv18425
> > > >
> > > > Modified Files:
> > > >       binfer.l
> > > > Log Message:
> > > >
> > > > Changed to elliminate `dangerous trailing context' warning: caused parse
> > > > failure (in binfer.y) on linux-i386 at least
> > >
> > > On cray I get:
> > > /home/t3e/fsn/nhdc/nhdcmark/grass/src/raster/r.binfer
> > >   make -f OBJ.alpha-cray-unicosmk2.0.4.X/make.rules
> > >
> > >         rm -f lex.c gram.c
> > >         yacc binfer.y
> > >         rm -f gram.c
> > >         mv y.tab.c gram.c
> > >         cc -g   -I/home/t3e/fsn/nhdc/nhdcmark/grass/src/include  -c gram.c
> > > -o OBJ.alpha-cray-unicosmk2.0.4.X/gram.o
> > >         lex binfer.l
> > > "binfer.l":line 13: Error: Missing translation value
> > > Make: "lex binfer.l": Error code 1
> > >
> > > But it is lex there, not flex:
> > >      lex - Generates programs for simple lexical tasks
> > >    STANDARDS
> > >      POSIX, XPG4
> > >
> > > well, let's ignore CRAY...
> > >
> > > Thanks for updating
> > >
> > >  Markus
> > >
> >
> > Hi Markus
> >
> > Do you know exactly what lex Cray uses? The problem seems to be the
> > %option statement. So perhaps we could get round that by putting in
> > conditional code, as Cray presumably doesn't need the lex-compat
> > statement. Do you [anyone] know off-hand the definition code for Cray?
> 
> Hi David,
> 
> how can I find out?
> 
> man lex
> LEX(1)                        UNICOS/mk 2.0.4         Last changed: 2-24-98
> NAME
>      lex - Generates programs for simple lexical tasks
> 
> SYNOPSIS
>      lex [-t] [-r] [-n] [files]
>      lex [-t] [-r] [-v] [files]
> 
>      Obsolescent version; may not be supported in future releases:
> 
>      lex -c [-t] [-r] [-n] [files]
>      lex -c [-t] [-r] [-v] [files]
> 
> IMPLEMENTATION
>      CRAY T3E systems
> 
> STANDARDS
>      POSIX, XPG4
>      AT&T extensions (-r option)
> [...]
> SEE ALSO
>      yacc(1)
> 
>      lex & yacc, Doug Brown and Tony Mason, O'Reilly & Associates, Inc.,
>      1992.

This is my reference. The above suggests that the cray lex is probably a
posix lex, as described here.

> 
>      The UNIX Programming Environment, Brian W. Kernighan and Rob Pike,
>      Prentice-Hall, Inc., 1984.
> 
>      UNICOS/mk User Commands Reference Manual, publication SR-2611, for the
>      printed version of this man page.
> 
> Is there anything else I could try?
> 
> Markus
> 

I think the following is the solution:

Remove `%option lex-compat' from the scanner file. This is a flex
feature and so other lex's will not recognise it. Also comment out
references to `yylineno' in stable code. A file is included with a list
of the locations of yylineno locations so that anyone hacking on the
module can restore them if required [?]. During this development and
testing the `LEX= flex -l' option would be available
in the Gmakefile, otherwise commented out.

The best way would still be to use conditional code with an environment
variable like LEX_IS_FLEX, when set it would allow the LEX variable to
be over-ridden in the local Gmakefile depending on whether the lex on
the system is _really_ flex. But - how do you determine that?

I haven't committed these changes yet. I wanted to wait if anyone had
any objections. 

David

---------------------------------------- 
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo at geog.uni-hannover.de with
subject 'unsubscribe grass5'