> 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. Thanks! cheers ./daniel -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
