Thread: Autoconf 2.69 update
I'm proposing that we upgrade our Autoconf to 2.69, which is the latest right now (release date 2012-04-24). There are no changes in the source needed, just tweak the version number in configure.in (see below) and run autoreconf. I've compared the configure output before and after on a few boxes, and there were no significant changes. The major benefit of this update is that configure shrinks to about half the size and also runs a bit faster. Maybe at this time, everyone who is interested can check that they have an installation of Autoconf 2.69 around, and then in a few weeks we can do the update. diff --git a/configure.in b/configure.in index a4baeaf..ac61be5 100644 --- a/configure.in +++ b/configure.in @@ -19,7 +19,7 @@ m4_pattern_forbid(^PGAC_)dnl to catch undefined macrosAC_INIT([PostgreSQL], [9.4devel], [pgsql-bugs@postgresql.org]) -m4_if(m4_defn([m4_PACKAGE_VERSION]), [2.63], [], [m4_fatal([Autoconf version 2.63 is required. +m4_if(m4_defn([m4_PACKAGE_VERSION]), [2.69], [], [m4_fatal([Autoconf version 2.69 is required.Untested combinations of 'autoconf'and PostgreSQL versions are notrecommended. You can remove the check from 'configure.in' but it is thenyour responsibilitywhether the result works or not.])])
On Fri, Nov 15, 2013 at 12:00 PM, Peter Eisentraut <peter_e@gmx.net> wrote: > I'm proposing that we upgrade our Autoconf to 2.69, which is the latest > right now (release date 2012-04-24). There are no changes in the source > needed, just tweak the version number in configure.in (see below) and > run autoreconf. I've compared the configure output before and after on > a few boxes, and there were no significant changes. > The major benefit of this update is that configure shrinks to about half > the size and also runs a bit faster. +1 for the update. > Maybe at this time, everyone who is interested can check that they have > an installation of Autoconf 2.69 around, and then in a few weeks we can > do the update. Archlinux boxes will be happier with that. Regards, -- Michael
15.11.2013 05:00, Peter Eisentraut kirjoitti: > I'm proposing that we upgrade our Autoconf to 2.69, which is the latest > right now (release date 2012-04-24). There are no changes in the source > needed, just tweak the version number in configure.in (see below) and > run autoreconf. I've compared the configure output before and after on > a few boxes, and there were no significant changes. +1. Autoconf 2.63 doesn't seem to be available as a package on recent Linux distributions and would make things easier for me. > -m4_if(m4_defn([m4_PACKAGE_VERSION]), [2.63], [], [m4_fatal([Autoconf version 2.63 is required. > +m4_if(m4_defn([m4_PACKAGE_VERSION]), [2.69], [], [m4_fatal([Autoconf version 2.69 is required. > Untested combinations of 'autoconf' and PostgreSQL versions are not > recommended. You can remove the check from 'configure.in' but it is then > your responsibility whether the result works or not.])]) 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? 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. That said, it looks like autoconf 2.67 (from Debian 6) can't handle = in a cflags test, so maybe not.. / Oskari *** # Generated by GNU Autoconf 2.67 for PostgreSQL 9.4devel. ... checking whether gcc supports -fexcess-precision=standard... ./configure: line 4528: pgac_cv_prog_cc_cflags__fexcess_precision_standard=no: command not found
Oskari Saarenmaa <os@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
On 2013-11-20 09:53:53 -0500, Tom Lane wrote: > 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. The committer maybe, but it's a PITA for reviewers on machines without the matching autoconf version around. Which at least currently frequently isn't packaged anymore... Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
On Wed, Nov 20, 2013 at 3:58 PM, Andres Freund <andres@2ndquadrant.com> wrote:
The committer maybe, but it's a PITA for reviewers on machines without
On 2013-11-20 09:53:53 -0500, Tom Lane wrote:
> 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.
the matching autoconf version around. Which at least currently
frequently isn't packaged anymore...
That's going to be a PITA whichever way you go, though, because there is not one standard about which autoconf version distros have. It's certainly not all that have 2.69. I frequently do my builds on Ubuntu 12.04 for example, which has 2.15, 2.59, 2.64 and 2.68 (don't ask me how they ended up with that combination).
The point is - regardless of which version you chose, reviewers and committers are going to have to deal with a local installation in many cases anyway. So we might be better off just documenting that in a more clear way.
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
On 11/20/2013 10:28 AM, Magnus Hagander wrote: > > On Wed, Nov 20, 2013 at 3:58 PM, Andres Freund <andres@2ndquadrant.com > <mailto:andres@2ndquadrant.com>> wrote: > > > On 2013-11-20 09:53:53 -0500, Tom Lane wrote: > > 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. > > The committer maybe, but it's a PITA for reviewers on machines without > the matching autoconf version around. Which at least currently > frequently isn't packaged anymore... > > > That's going to be a PITA whichever way you go, though, because there > is not one standard about which autoconf version distros have. It's > certainly not all that have 2.69. I frequently do my builds on Ubuntu > 12.04 for example, which has 2.15, 2.59, 2.64 and 2.68 (don't ask me > how they ended up with that combination). > > The point is - regardless of which version you chose, reviewers and > committers are going to have to deal with a local installation in many > cases anyway. So we might be better off just documenting that in a > more clear way. > > And it only matters if you're reviewing things that touch the configure setup. That's a tiny minority of patches. cheers andrew
On Wed, Nov 20, 2013 at 4:31 AM, Oskari Saarenmaa <os@ohmu.fi> wrote: > 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? 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. -1 from me. Dropping configure from the repository would significantly increase the burden to compile and install PostgreSQL from source. Not everyone has autoconf installed. -1 also for loosening the version check. I guarantee that if we do that, people will use varying versions when regenerating configure, and we'll have a mess. Even if we standardize the version committers are supposed to use, someone will foul it up at least twice a year. The last thing I need is to have more things that I can accidentally screw up while committing; the list is too long already. I realize that those checks are a bit of a nuisance, but if they bother you you can just whack them out locally and proceed. Or else you can download and compile the right version of autoconf. If you're doing sufficiently serious development that you need to touch configure.in, the 5 minutes it takes you to build a local install of the right autoconf version should be the least of your concerns. It's not hard; I've done it multiple times, and have multiple versions of autoconf installed on those systems where I need to be able to re-run autoconf on any supported branch. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
20.11.2013 23:38, Robert Haas kirjoitti: > On Wed, Nov 20, 2013 at 4:31 AM, Oskari Saarenmaa <os@ohmu.fi> wrote: >> 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? 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. > > -1 from me. Dropping configure from the repository would > significantly increase the burden to compile and install PostgreSQL > from source. Not everyone has autoconf installed. I think it's reasonable to assume that people who build from git have autoconf. The release tarballs should still contain the generated configure, etc; I believe this is how a lot of (most?) open source projects handle autoconf artifacts. > -1 also for loosening the version check. I guarantee that if we do > that, people will use varying versions when regenerating configure, > and we'll have a mess. Even if we standardize the version committers > are supposed to use, someone will foul it up at least twice a year. > The last thing I need is to have more things that I can accidentally > screw up while committing; the list is too long already. > > I realize that those checks are a bit of a nuisance, but if they > bother you you can just whack them out locally and proceed. Or else > you can download and compile the right version of autoconf. If you're > doing sufficiently serious development that you need to touch > configure.in, the 5 minutes it takes you to build a local install of > the right autoconf version should be the least of your concerns. It's > not hard; I've done it multiple times, and have multiple versions of > autoconf installed on those systems where I need to be able to re-run > autoconf on any supported branch. As long as the released tarballs contain generated scripts I don't really see this being an issue. While changes to configure.in are pretty rare, they do happen and when you have to modify configure the resulting 'git diff', 'git status' etc become unnecessarily large and require you to hand-edit the patches before sending them to the mailing list, etc. One more option would be to include the built configure in release branches as there shouldn't really be many changes to configure.in after branching and it'd make sure that all build farm builders test the same script generated by a known version. Anyway, I won't mind the strict requirement for autoconf that much if it's for a more recent version than 2.63 :-) / Oskari
On Thu, 2013-11-14 at 22:00 -0500, Peter Eisentraut wrote: > I'm proposing that we upgrade our Autoconf to 2.69 This has been done.