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 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs