Oskari Saarenmaa <o...@ohmu.fi> writes:
> ISTM autoconf has been better with backwards compatibility lately.
> Maybe the fatal error could be changed to a warning and/or the check for
> version == 2.63 be replaced with a check for version >= 2.63?
Seems a bit risky to me. Now, Red Hat diked that test out for years
in their packages, and didn't get burnt. But they are not known for
shipping bleeding-edge versions of autoconf. And more to the point,
they (I) would've taken full responsibility for dealing with any
ensuing breakage. If we remove the version test from configure.in,
then it becomes *our* problem if it doesn't work with $random autoconf.
> Without a
> strict requirement for a certain autoconf version it would make sense to
> also drop the built autoconf artifacts from the git repository which
> would make diffs shorter and easier to review when touching configure.in.
If we dropped the configure script from git, then buildfarm testing would
provide essentially no confidence that the exact script we'd ship in a
release would have gotten any testing, other than on machines configured
identically to the one we build release tarballs on. Which sort of
defeats the purpose of buildfarm testing.
As a rule, you're not supposed to bother including the configure output
script in a submitted diff anyway. Certainly any committer worth his
commit bit is going to ignore it and redo autoconf for himself.
Personally, I keep all the active branches' autoconf versions installed
in /usr/local/autoconf-N.NN/, and the script I use to switch my attention
to one or another active branch includes changing my PATH to put
the appropriate /usr/local/autoconf-N.NN/bin/ in front of /usr/bin.
So I don't have to think about this, other than occasionally needing
to install a new autoconf version from source. But that's a good thing
anyway --- I think it's a good idea to avoid using distro-supplied
autoconfs for this, because that might make it hard for another committer
to reproduce the identical results.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
