Re: automake1.6 & AM_PATH_PYTHON & lib64

[Alexandre Duret-Lutz]

Happy new year,

Please write to mailing lists, not to people, so 
your mail gets read by more people, archived, searchable... 
and so I don't have to quote it entirely :)

|  From: Gwenole Beauchesne <address@hidden>
|  Subject: automake1.6 & AM_PATH_PYTHON & lib64
|  To: address@hidden
|  Cc: address@hidden, <address@hidden>
|  Date: Mon, 6 Jan 2003 19:00:21 +0100 (CET)
|  
|  Hi,
|  
|  Enclosed is a patch to fix AM_PATH_PYTHON on lib64 platforms with
|  automake1.6+. Please review and apply and hope developers will update 
|  their aclocal.m4 with newer automake from upcoming distros. ;-)
|  
|  Basically, we (MDK, RedHat, SuSE) appear to all use %{_libdir}/python2.2/
|  as Python home directory by now. %_libdir expands to /usr/lib64 on lib64
|  platforms (e.g. x86-64). However, some packages were still hardcoding path
|  to python home. That includes automake.
|  
|  Note: the patch assumes distutils to exist. I actually don't know when it 
|  appeared in Python history. Otherwise, we can still do the usual machinery 
|  to detect a lib64 platform or not.

python.m4 supports Python back to version 1.5, which --
unfortunately -- doesn't come with distutils.

% python1.5 -c "from distutils import sysconfig"
Traceback (innermost last):                                            
  File "<string>", line 1, in ?
ImportError: No module named distutils

Another issue is that $pythondir should start with the value of
$PYTHON_PREFIX, not /usr.  Otherwise prefix substitutions at
install-time (e.g., make prefix=/tmp install) won't work
properly.  Looking at the distutils code, it seems this can be
sorted out with the third argument of sysconfig.get_python_lib().


It seems the distutils module was introduced in Python 1.6, and
that 64-bit machines were not yet supported at this time.
(The 2.0 beta 1 release notes say:

  Trent Mick ensured portability to 64-bit platforms, under both Linux
  and Win64, especially for the new Intel Itanium processor.  Mick also
  added large file support for Linux64 and Win64.)

So maybe we could just run your distutils query, and fall
back to the hard coded path when it doesn't run?

|  
|  Bye,
|  Gwenole.
|  
|  --- automake-1.7.2/m4/python.m4.python-libdir        2002-08-24 
14:46:03.000000000 +0200
|  +++ automake-1.7.2/m4/python.m4      2003-01-06 17:40:33.000000000 +0100
|  @@ -117,8 +117,9 @@ AC_DEFUN([AM_PATH_PYTHON],
|     dnl Also, if the package prefix isn't the same as python's prefix,
|     dnl then the old $(pythondir) was pretty useless.
|   
|  -  AC_SUBST([pythondir],
|  -       [$PYTHON_PREFIX"/lib/python"$PYTHON_VERSION/site-packages])
|  +  AC_CACHE_CHECK([for $am_display_PYTHON scripts dir], 
[am_cv_python_pythondir],
|  +    [am_cv_python_pythondir=`$PYTHON -c "from distutils import sysconfig; 
print sysconfig.get_python_lib(0)"`])
|  +  AC_SUBST([pythondir], [$am_cv_python_pythondir])
|   
|     dnl pkgpythondir -- $PACKAGE directory under pythondir.  Was
|     dnl   PYTHON_SITE_PACKAGE in previous betas, but this naming is
|  @@ -130,8 +131,9 @@ AC_DEFUN([AM_PATH_PYTHON],
|     dnl pyexecdir -- directory for installing python extension modules
|     dnl   (shared libraries)  Was PYTHON_SITE_EXEC in previous betas.
|   
|  -  AC_SUBST([pyexecdir],
|  -       [${PYTHON_EXEC_PREFIX}/lib/python${PYTHON_VERSION}/site-packages])
|  +  AC_CACHE_CHECK([for $am_display_PYTHON extension modules dir], 
[am_cv_python_pyexecdir],
|  +    [am_cv_python_pyexecdir=`$PYTHON -c "from distutils import sysconfig; 
print sysconfig.get_python_lib(1)"`])
|  +  AC_SUBST([pyexecdir], [$am_cv_python_pyexecdir])
|   
|     dnl pkgpyexecdir -- $(pyexecdir)/$(PACKAGE)
|     dnl   Maybe this should be put in python.am?
 
-- 
Alexandre Duret-Lutz