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
