gluster-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gluster-devel] python version


From: Kaleb S. KEITHLEY
Subject: Re: [Gluster-devel] python version
Date: Mon, 14 May 2012 10:17:12 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1

On 05/13/2012 10:42 AM, Emmanuel Dreyfus wrote:
Hi

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 automake.

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?

--

Kaleb



reply via email to

[Prev in Thread] Current Thread [Next in Thread]