[Gluster-devel] python version
Kaleb S. KEITHLEY
kkeithle at redhat.com
Mon May 14 14:17:12 UTC 2012
On 05/13/2012 10:42 AM, Emmanuel Dreyfus wrote:
> There is a problem with python version detection in the configure
> script. The machine on which autotools is ran prior releasing glusterfs
> expands AM_PATH_PYTHON into a script that fails to accept python> 2.4.
> As I understand, a solution is to concatenate latest
> automake-1.12/m4/python.m4 into glusterfs' aclocal.m4. That way python
> up to 3.1 should be accepted. Opinions?
The aclocal.m4 file is produced when (/usr/bin/)aclocal is invoked by
./autogen.sh file in preparation for building gluster. (You have to run
autogen.sh to produce the ./configure file.)
aclocal uses whatever python.m4 file you have on your system, e.g.
/usr/share/aclocal-1.11/python.m4, which is also from the automake package.
I presume whoever packages automake for a particular system is taking
into consideration what other packages and versions are standard for the
system and picks right version of automake. IOW picks the version of
automake that has all the (hard-coded) versions of python to match the
python they have on their system.
If someone has installed a later version of python and not also updated
to a compatible version of automake, that's not a problem that gluster
should have to solve, or even try to solve. I don't believe we want to
require our build process to download the latest-and-greatest version of
As a side note, I sampled a few currently shipping systems and see that
the automake shipped with/for Fedora 16 and 17, FreeBSD 8.2 and 8.3, and
NetBSD 5.1.2, is automake-1.11, which has all the appearances of
supporting python 2.5 (and 3.0).
Finally, after all that, note that the configure.ac file appears to be
hard-coded to require python 2.x, so if anyone is trying to use python
3.x, that's doomed to fail until configure.ac is "fixed." Do we even
know why python 2.x is required and why python 3.x can't be used?
More information about the Gluster-devel