Re: AC_PROG_LEX behavior

[Ralf Wildenhues]

Hi Patrick,

* Patrick Welche wrote on Wed, Jun 03, 2009 at 11:36:17AM CEST:
> On Fri, Mar 21, 2008 at 10:29:05AM -0400, Stefan Seefeld wrote:
> > I'm trying to use AC_PROG_LEX to discover whether flex (or lex) is
> > available. During testing I found out that, even when neither is
> > available, the LEX variable is set to ':' instead of being empty.
> > And sure enough, I subsequently found this in the programs.m4 code:
> > 
> > 
> > AC_DEFUN_ONCE([AC_PROG_LEX],
> > [AC_CHECK_PROGS(LEX, flex lex, :)
> > if test "x$LEX" != "x:"; then
> >   _AC_PROG_LEX_YYTEXT_DECL
> > fi])
> > 
> > Is this intentional ? Is it documented somewhere ? In other words, is it
> > ok for me to check for "test $LEX != ':'" to discover success ?

Hmm.  I'd probably say that would be ok.  Not because I think it is a
good idea to document that LEX is set to ':' when not found, but because
I think we cannot change that anyway because software relies on it.

When looking at the semantics of program searches in case of failure,
we have been using different fallback values, typically in a way that
suited the primary intended use.  For example, the intention here is
that packages using autotools (i.e., also Automake) will ship the files
generated by (f)lex alongside the .l file, so if the user happens to not
have flex or lex installed, that is no big issue, and ':' will do the
job of not touching the file and also allowing 'make' to succeed.

With some other tools, we choose 'false' if they are not present because
we want builds to generally fail without them.

So, if Eric wants to adjust the documentation to reflect the ':' value
of LEX here, I'd be fine with that.

> While here, I just hit the following problem:
> 
> User has old flex in /usr/bin/flex, and new flex in /usr/local/bin,
> so calls "./configure LEX=/usr/local/bin/flex" to configure the
> program which needs new flex. The problem is that AC_PROG_FLEX's
> description is
> 
>      If `flex' is found, set output variable `LEX' to `flex'...
> 
> so the program's configure.ac tests
> 
>           if test "$LEX" != flex; then
> 
> as a way of testing flex vs lex, and decides that there is no flex.
> 
> So, essentially, $LEX is being used for two things: "this is where my
> lexer lives" and "this is real flex".

I wouldn't read it that way.  Agreed, the documentation is terse, but
it's not wrong: LEX is set to flex if flex is found (note I'm using if
not iff a.k.a. if and only if).  If the user overrides LEX, well, then
the configure test does not search, so in some sense, there is no
"found" there either (way to go splitting hairs...)

I think we should adjust the documentation to be clearer.  You could use
  case $LEX in flex | flex$EXEEXT | */flex | */flex$EXEEXT ) ... ;; esac

then but of course the user could still fool you by adding a wrapper
script for a non-flex lex or some other program.  Thus I think the
configure.ac test should just try to execute `$LEX --version' or look
for some needed option in the --help output or so.

Suggestions for the doc change welcome.

Cheers,
Ralf