On 06/30/2013 11:07 AM, Andres Freund wrote:
On 2013-06-30 10:17:50 -0400, Andrew Dunstan wrote:
On 06/30/2013 09:49 AM, Tom Lane wrote:
Andrew Dunstan <and...@dunslane.net> writes:
On 2013-06-30 15:17:20 +0200, Andres Freund wrote:
Andrew: Could we perhaps check for the "Report this to" bit in the
buildfarm?
I'm not sure what you're asking here.
I think he's wishing that if configure prints something like
configure: WARNING: sys/ucred.h: present but cannot be compiled
configure: WARNING: sys/ucred.h: check for missing prerequisite headers?
configure: WARNING: sys/ucred.h: see the Autoconf documentation
configure: WARNING: sys/ucred.h: section "Present But Cannot Be Compiled"
configure: WARNING: sys/ucred.h: proceeding with the preprocessor's result
configure: WARNING: sys/ucred.h: in the future, the compiler will take
precedence
configure: WARNING: ## ---------------------------------------- ##
configure: WARNING: ## Report this to pgsql-bugs@postgresql.org ##
configure: WARNING: ## ---------------------------------------- ##
that that ought to be treated as a failure not a success. I'm not
entirely sure that I agree, but it's an arguable position.
Exactly. That we presumably had this warning showing up for more than 2
years seems to indicate we should think about doing something different.
Oh. Well, if that's a failure then it's up to configure to treat it as one.
The buildfarm doesn't second-guess the exit status of the various steps, and
it doesn't report warnings - if it did we'd be flooded.
I guess we don't want to do that because it would probably hurt people
building in unusual environments where some variants of this very well
can show up without stopping pg from being built. Many people on such
problems will have no difficulties fixing a minor compilation error, but
fixing configure.in + installing the correct autoconf version is a
higher barrier.
We could add a --strict-mode or so to configure, but afair the handling
of that warning is burried in autoconf itself making this harder. So
I thought adding some grep like thing to the buildfarm might be the
easiest solution.
But that *would* be second-guessing configure's exit status.
I don't understand the reference to autoconf - nobody building Postgres,
including buildfarm members, needs autoconf installed at all. Only
developers and committers need to, and then only when configure.in is
changed.
cheers
andrew
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
