[GRASS5] [bug #883] (grass) configure dosn't look for yacc

this bug's URL: http://intevation.de/rt/webrt?serial_num=883
-------------------------------------------------------------------------

Subject: configure dosn't look for yacc

Platform: Linux/Intel
Linux distro: RedHat
linux cpu: Intel (i486, i586, pentium ...)
Xwindows version: Xfree 4.0.x
Xwindows manager: KDE 2.x
TclTk version: tcl/tk 8.3
grass downloaded at: CVS Server, Germany
grass binary for platform: I compiled the sources myself
grass sources source: yes, I am using the latest GRASS from CVS
c compiler name: gcc

configure doesn't assure that yacc is installed on the
system, so at the make stage programs that depend on
yacc fail to compile (like r.mapcalc)...
it is possible to look it in the error.log file and
then test with gmake5, but
it would be better if configure could test it since it
is a requirement for compilation...

-------------------------------------------- Managed by Request Tracker

Request Tracker wrote:

configure doesn't assure that yacc is installed on the
system, so at the make stage programs that depend on
yacc fail to compile (like r.mapcalc)...

I've added checks for lex and yacc.

--
Glynn Clements <glynn.clements@virgin.net>

On the subject of lex/flex, configure.in currently has the following:

if test "$LEX" != "flex"; then
    AC_MSG_WARN([Consider installation of flex (replacement of lex).])
fi

Does anyone know the reason for this message?

If the .l files *need* flex, then this should be an error. OTOH, if
they work with lex, there doesn't seem much point in issuing a
warning.

--
Glynn Clements <glynn.clements@virgin.net>

Hi Glynn,

Glynn Clements wrote:

On the subject of lex/flex, configure.in currently has the following:

if test "$LEX" != "flex"; then
    AC_MSG_WARN([Consider installation of flex (replacement of lex).])
fi

Does anyone know the reason for this message?

i just forwarded the discussion from february 2000 on this to you.
Please look at the thread in the list.
As far as i remember we decided to standardize on flex.

HTH,

Andreas
--
Andreas Lange, 65187 Wiesbaden, Germany, Tel. +49 611 807850
url: http://mitglied.tripod.de/AndreasLange
mail: Andreas.Lange_at_Rhein-Main.de - A.C.Lange_at_GMX.net

Andreas Lange wrote:

> On the subject of lex/flex, configure.in currently has the following:
>
> if test "$LEX" != "flex"; then
> AC_MSG_WARN([Consider installation of flex (replacement of lex).])
> fi
>
> Does anyone know the reason for this message?

i just forwarded the discussion from february 2000 on this to you.

can we make flex a requirement for compiling of GRASS5?
The problem is now that some modules can be compiled with either flex or
lex, but one module uses an option "%option lex-compat" which is not
recognized by standard lex.

Currently, none of the .l files in either the release branch or the
head use "%option" directive. AFAICT, none of them use any flex
extensions either, so I've removed the warning.

--
Glynn Clements <glynn.clements@virgin.net>

On Fri, Dec 21, 2001 at 06:21:45PM +0000, Glynn Clements wrote:

On the subject of lex/flex, configure.in currently has the following:

if test "$LEX" != "flex"; then
    AC_MSG_WARN([Consider installation of flex (replacement of lex).])
fi

Does anyone know the reason for this message?

If the .l files *need* flex, then this should be an error. OTOH, if
they work with lex, there doesn't seem much point in issuing a
warning.

Glynn,

the reason is that we had problems with "yylineno" in the past (if
I recall properly). In:
src/raster/r.binfer/binfer.l

Flex provides something which is not always provided by lex.
Mhhh, long time ago.

Markus

Markus Neteler wrote:

> On the subject of lex/flex, configure.in currently has the following:
>
> if test "$LEX" != "flex"; then
> AC_MSG_WARN([Consider installation of flex (replacement of lex).])
> fi
>
> Does anyone know the reason for this message?
>
> If the .l files *need* flex, then this should be an error. OTOH, if
> they work with lex, there doesn't seem much point in issuing a
> warning.

the reason is that we had problems with "yylineno" in the past (if
I recall properly). In:
src/raster/r.binfer/binfer.l

OK; currently, the references to yylineno are commented out.

If the line number is required, it's probably better to include code
to track it, rather than have (f)lex do it for you.

Flex provides something which is not always provided by lex.

AFAIK, AT&T lex does provide yylineno, but it is undocumented;
yylineno isn't part of the POSIX specification for lex.

Also, the flex manpage states that "%option yylineno" results in a
significant performance penalty (although control files aren't
generally large enough to be worth bothering about performance).

--
Glynn Clements <glynn.clements@virgin.net>