On 2013-07-01 09:19:23 -0400, Tom Lane wrote: > Peter Eisentraut <pete...@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 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
