Re: 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 macros

AC_INIT([PostgreSQL], [9.4devel], [pgsql-bugs(at)postgresql(dot)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 not
recommended. You can remove the check from 'configure.in' but it is then
your responsibility whether the result works or not.])])

On Fri, Nov 15, 2013 at 12:00 PM, Peter Eisentraut <peter_e(at)gmx(dot)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(at)ohmu(dot)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(at)2ndquadrant(dot)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.

--
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(at)2ndquadrant(dot)com
> <mailto:andres(at)2ndquadrant(dot)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(at)ohmu(dot)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(at)ohmu(dot)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.