On 2013-06-30 11:19:50 -0400, Andrew Dunstan wrote:
> >>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.
Yes. I think that's the easiest thing in this case.
> 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.
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.
Given that many of those warnings will *NOT* completely prohibit them
from building postgres that might be overreaching.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services