Thread: Make flex/bison checks stricter in Git trees

When running ./configure on a system without Flex/Bison it’s easy to miss the
warning that flies past and then run into compilation error instead.  When it
happened to a colleague yesterday a brief discussion came to the conclusion
that it would be neat it the flex and bison checks took the existence of the
generated files into consideration.

Attached patch scans for the generated files and iff flex or bison isn’t found
in a non-cross compilation build, errors out in case the generated filed don’t
exist while retaining the warning in case they do.  This maintains the current
warning message for downloaded distribution trees while it make the check
strict on Git trees.  It does add a hardcoded list of files which it can be
argued how nice that is even though the list rarely change (there might be a
cleaner way but I couldn’t see one).  Also includes a tiny copy-edit fix on the
flex warning to make it match the bison one since that seemed better.

If this is at all of interest I can add to the commitfest.

cheers ./daniel

Daniel Gustafsson <daniel@yesql.se> writes:
> When running ./configure on a system without Flex/Bison it’s easy to miss the
> warning that flies past and then run into compilation error instead.  When it
> happened to a colleague yesterday a brief discussion came to the conclusion
> that it would be neat it the flex and bison checks took the existence of the
> generated files into consideration.

> Attached patch scans for the generated files and iff flex or bison isn’t found
> in a non-cross compilation build, errors out in case the generated filed don’t
> exist while retaining the warning in case they do.

Not exactly convinced this is a good idea.  What if the files exist but
are out of date?  More generally, how much advantage is there really in
failing at configure rather than build time?

The subtext here is that I'm disinclined to load more behavior into
configure while we're waiting to see if cmake conversion happens.
That job is tough enough without the autoconf sources being more of
a moving target than they have to be.
        regards, tom lane

> On 27 Sep 2016, at 15:49, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Daniel Gustafsson <daniel@yesql.se> writes:
>> When running ./configure on a system without Flex/Bison it’s easy to miss the
>> warning that flies past and then run into compilation error instead.  When it
>> happened to a colleague yesterday a brief discussion came to the conclusion
>> that it would be neat it the flex and bison checks took the existence of the
>> generated files into consideration.
>
>> Attached patch scans for the generated files and iff flex or bison isn’t found
>> in a non-cross compilation build, errors out in case the generated filed don’t
>> exist while retaining the warning in case they do.
>
> Not exactly convinced this is a good idea.  What if the files exist but
> are out of date?

Wouldn’t that be the same as today if so?

> More generally, how much advantage is there really in
> failing at configure rather than build time?

The error reporting is clearer IMO but it’s a matter of taste.

> The subtext here is that I'm disinclined to load more behavior into
> configure while we're waiting to see if cmake conversion happens.
> That job is tough enough without the autoconf sources being more of
> a moving target than they have to be.

Fair enough, that’s a very valid argument.

Thanks!

cheers ./daniel