Обсуждение: autoconf trouble in the CVS HEAD
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. Thanks, -- OSS Platform Development Division, NEC KaiGai Kohei <kaigai@ak.jp.nec.com>
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