> On 27 Sep 2016, at 15:49, Tom Lane <t...@sss.pgh.pa.us> wrote:
> Daniel Gustafsson <dan...@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.


cheers ./daniel

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to