Re: [PATCH] configure: Check for flex

[Roger Pau Monne <roger.pau@citrix.com>]

Ian Jackson escribió:
> Roger Pau Monne writes ("Re: [Xen-devel] [PATCH] configure: Check for flex"):
>> El 15/04/2012, a las 19:43, Jean Guyader escribió:
>>> libxl require the command flex to be present.
>>> Verify in the configure script that the flex
>>> command exsits.
>>>
>>> Signed-off-by: Jean Guyader<jean.guyader@gmail.com>
>>
>> I've already sent a patch for this, detecting and setting Flex and Bison at configure, and printing a pretty error message if libxl needs them and they are not found:
>>
>> http://lists.xen.org/archives/html/xen-devel/2012-04/msg00923.html
>
> (I'm afraid that patch is still in my (enormous) backlog, but:)
>
> I'm not very convinced that that patch is an improvement.  All it
> does, effectively, is change the error message from "flex: not found"
> to a custom one which effectively says "I couldn't find flex".

It also adds automatic detection of flex/bison from configure, so if the 
user has those installed, and they are needed, the compilation will not 
fail (without this patch the compilation will just fail).

> If flex is not available, and the timestamps indicate the file needs
> to be rebuilt, we have two choices, corresponding to two possible
> situations:
>    1. Assume that the problem is simply timestamp skew, and allow
>       the build to continue without regenerating the file (although
>       we should probably print a warning)
>    2. Assume that the user has edited (or patched) the flex source
>       code, and stop with an error
>
> Of these I think 1. is preferable.  In the latter case, if the user
> edited it themselves they will hopefully be reading the make output
> and see the warning; whereas if the user applied a patch, the patch
> should update the flex output too.
>
> In practice we update these files rarely and of course we always
> commit a corresponding change.  So doing 1. will only adversely affect
> a small minority of developers.  Whereas doing 2. seems to cause
> regular annoyance to many people who don't necessarily know what's
> going on.
>
> Ian.