Re: [HACKERS] 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 ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] autoconf trouble in the CVS HEAD
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 [EMAIL PROTECTED] ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] autoconf trouble in the CVS HEAD
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 ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] autoconf trouble in the CVS HEAD
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 [EMAIL PROTECTED] http://www.gregsmith.com Baltimore, MD ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] autoconf trouble in the CVS HEAD
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 [EMAIL PROTECTED] ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] autoconf trouble in the CVS HEAD
Greg Smith [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
