On 2013-07-01 09:19:23 -0400, Tom Lane wrote:
> Peter Eisentraut <peter_e@gmx.net> writes:
> > On 6/30/13 11:26 AM, Andres Freund wrote:
> >> If we would treat that warning as an error unconditionally - and I am
> >> not sure how easy that is given the way it's emitted - users
> >> encountering them, which usually will be on less common platforms, will
> >> have to patch configure.in to make things work for them. Which is a high
> >> bar.
>
> > We could also look into updating Autoconf. Newer versions proceed with
> > the compiler's result. At that point, you can essentially ignore the
> > warning.
While it has other benefits, changing whether autoconf believes the
precompiler or the compiler doesn't seem to fix the issue of tests that
fail silently (as in, don't abort autoconf) because we missed to include
prerequisite headers.
And it doesn't seem to make it neither easier, nor harder for users to
fix configure.in, so unconditionally throwing an hard error even if we
could manage it would still not a good solution.
> AFAICT, the result in this case would be that the script comes to the
> wrong conclusion about whether ucred.h is available. Wouldn't that
> result in a build failure, or at least missing features? IOW, don't
> we need to fix this test anyway?
Yes, we need to. I vote for applying something similar to what I
proposed upthread. If we can get rid of some redundancy by using a newer
autoconf we need to touch far more than this tiny bit...
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services