autoconf trouble in the CVS HEAD

KaiGai Kohei wrote:

I found a tiny fix for configure.in at Nov 26.

http://developer.postgresql.org/cvsweb.cgi/pgsql/configure.in.diff?r1=1.537;r2=1.538;f=h

It seems to me this check enforces us to use autoconf 2.59, not the latest one.
Is there any reason for this change?

For example, autoconf 2.61 is installed in the Fedora 7, 8 and rawhide,
so this chage will be troubled for many developers.

Who does this affect in practice? You don't need to run autoconf to
build postgres, only to change it.

cheers

andrew

Andrew Dunstan wrote:

KaiGai Kohei wrote:

I found a tiny fix for configure.in at Nov 26.

http://developer.postgresql.org/cvsweb.cgi/pgsql/configure.in.diff?r1=1.537;r2=1.538;f=h

It seems to me this check enforces us to use autoconf 2.59, not the latest one.
Is there any reason for this change?

For example, autoconf 2.61 is installed in the Fedora 7, 8 and rawhide,
so this chage will be troubled for many developers.

Who does this affect in practice? You don't need to run autoconf to
build postgres, only to change it.

Indeed, you are correct.
It is not affect for _many_ developers. :)

However, I added a new configure option (--enable-selinux) in my branch,
so I got a trouble on running autoconf.

I want to know the reason why the version of autoconf is fixed, to avoid
this trouble with an appropriate way in my branch.

The CVS commit log does not give us enough information...

Require a specific Autoconf version, instead of a lower bound only.

Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@ak.jp.nec.com>

On Wed, 19 Dec 2007, KaiGai Kohei wrote:

It seems to me this check enforces us to use autoconf 2.59, not the latest one.
Is there any reason for this change?

2.59 is the stable version of autoconf PostgreSQL 8.3 is built against,
and the check keeps anyone from accidentally running it against other
versions. Since as you've noticed some popular OSes have switched to
2.61, that test was put in there to keep people building a new configure
to give out to everyone from accidentally building against the wrong
version. The brutally long thread at
http://archives.postgresql.org/pgsql-hackers/2007-11/msg00706.php gives
more background on this topic.

--
* Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD

KaiGai Kohei wrote:

Andrew Dunstan wrote:

KaiGai Kohei wrote:

I found a tiny fix for configure.in at Nov 26.

http://developer.postgresql.org/cvsweb.cgi/pgsql/configure.in.diff?r1=1.537;r2=1.538;f=h

It seems to me this check enforces us to use autoconf 2.59, not the latest one.
Is there any reason for this change?

For example, autoconf 2.61 is installed in the Fedora 7, 8 and rawhide,
so this chage will be troubled for many developers.

Who does this affect in practice? You don't need to run autoconf to
build postgres, only to change it.

Indeed, you are correct.
It is not affect for _many_ developers. :)

However, I added a new configure option (--enable-selinux) in my branch,
so I got a trouble on running autoconf.

I want to know the reason why the version of autoconf is fixed, to avoid
this trouble with an appropriate way in my branch.

See discussion thread starting here:

http://archives.postgresql.org/pgsql-hackers/2007-11/msg00706.php

cheers

andreew

Andrew, Greg, Thanks for your infomation.

I've skimed through the thread.
It seems to me that using autoconf-2.59 and applying a patch to pre-built
configure is the most appropriate way to add an original configure option.

Thanks,

Greg Smith wrote:

On Wed, 19 Dec 2007, KaiGai Kohei wrote:

It seems to me this check enforces us to use autoconf 2.59, not the
latest one.
Is there any reason for this change?

2.59 is the stable version of autoconf PostgreSQL 8.3 is built against,
and the check keeps anyone from accidentally running it against other
versions. Since as you've noticed some popular OSes have switched to
2.61, that test was put in there to keep people building a new configure
to give out to everyone from accidentally building against the wrong
version. The brutally long thread at
http://archives.postgresql.org/pgsql-hackers/2007-11/msg00706.php gives
more background on this topic.

--
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@ak.jp.nec.com>

Greg Smith <gsmith@gregsmith.com> writes:

On Wed, 19 Dec 2007, KaiGai Kohei wrote:

It seems to me this check enforces us to use autoconf 2.59, not the latest one.
Is there any reason for this change?

The brutally long thread at
http://archives.postgresql.org/pgsql-hackers/2007-11/msg00706.php gives
more background on this topic.

The short answer to this is that if you want to re-run autoconf from
configure.in, and you want to use some other autoconf version than the
one the Postgres project officially supports for the particular PG
branch, you're free to patch that line out of configure.in and do what
you want. The check is in there to keep *us* from doing something we
don't want to do, which is to ship a version of the configure script
that we have not tested. When you override the project's choice of
autoconf version, it's entirely on your own head whether the result
works or not.

I'm not saying you shouldn't do this --- I'll very likely have to do it
myself in at least some Red Hat/Fedora branches. It's just that the
project isn't going to support these combinations.

regards, tom lane