Re: RFC: build: be robust to missing flex

[Stefano Lattarini]

Hi Akim, all, and sorry for the delay.

On 04/10/2012 09:43 PM, Akim Demaille wrote:
> [This started in bison-patches].
> 
> Le 27 mars 2012 à 16:27, Stefano Lattarini a écrit :
> 
>> On 03/27/2012 04:16 PM, Akim Demaille wrote:
>>>
>>> [BIG SNIP]
>>>
>>> diff --git a/configure.ac b/configure.ac
>>> index 622da5d..5c97683 100644
>>> --- a/configure.ac
>>> +++ b/configure.ac
>>> @@ -110,6 +110,9 @@ AC_SUBST([YACC_LIBRARY])
>>>
>>> # Checks for programs.
>>> AC_PROG_LEX
>>> +if $LEX --version 2>/dev/null | $EGREP 'f?lex 2\.5\.3' >/dev/null; then :; 
>>> else
>>> +  AC_MSG_ERROR([flex 2.5.3* is required])
>>> +fi
>>>
>> I think the best fix in the long term would be to enhance AC_PROG_LEX to set
>> a variable telling whether $LEX is flex or not (similarly to what is done by
>> AC_PROG_CC etc.).  The Bison's configure could simply use this variable to
>> determine whether a good-enough flex has been found.
>>
>> Would you think it worthwhile to submit a patch to Autoconf before 2.69 gets
>> released?
> 
> hi Stefano,
> 
> What do you think about this?  If this suits Autoconfers, I can
> provide a more complete patch for Autoconf.  And if good enough,
> AC_PROG_YACC will follow with Bison.
> 
> I confess I am a bit frustrated to define FLEX to yes/''
>
I agree with you, and in fact I find that confusing.  I understand that it
is done in order to be more consistent with what AC_PROG_CC and friends do,
but here clarity should win over consistency IMHO.

So what about naming the variable as 'LEX_IS_FLEX' instead?  And then
maybe, in follow-up patch (post-2.69), we could also introduce a similar
naming for the variables set by AC_PROG_CC and friends (e.g., 'CC_IS_GCC'
as an alias of what 'GCC' is currently defined to).  And then maybe, in a
further follow-up (for autoconf 3.0 perehaps?), deprecate the use of the
older variables (GCC and company).  How does this sound?

> as I'd
> be happy to use $(FLEX) in my Makefiles, but that's ok.  It hurts
> much more in the context of Bison, since the command line behavior
> is quite different in that case, so defining $(YACC) to be
> 'bison' and $(BISON) to be yes will probably be a bit weird.
>

Thanks for tacking this,
  Stefano