Re: BUG #8271: Configure warning: sys/ucred.h: present but cannot be compiled

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 <andrew@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