Re: automake and python

[Alexandre Duret-Lutz]

>>> "colliera" == colliera  <address@hidden> writes:

 colliera> hello,

Hello,

Sorry for the delay.

 colliera> i have a problem with the way that automake defines
 colliera> the "pyexecdir" (and "pkgpyexecdir")
 colliera> substitutions. they are derived from
 colliera> PYTHON_EXEC_PREFIX. now, by default,
 colliera> PYTHON_EXEC_PREFIX is defined as /usr/local. now this
 colliera> is fine on a system where python is installed under
 colliera> /usr/local, but many systems have it installed under
 colliera> /usr, with the result that new python packages are
 colliera> installed in a newly created directory
 colliera> /usr/local/lib/python2.3/site-packages. now python is
 colliera> looking under /usr/lib/python2.3/site-packages so it
 colliera> doesn't find these packages and nothing works.

This is what I'd expect.  

Besides it's not really unlike ${bindir}.  Many setup do not
include /usr/local/bin in the user's $PATH by default.  Users
have to add that directory to their PATH to use the package
installed there.  Likewise for ${libdir} and LD_LIBRARY_PATH.
For /usr/local/ python package it's the same, people or scripts
have to tell Python about the extra directory; I guess this can
also be setup site-wide.

 colliera> would it not be better to define:

 colliera> PYTHON_PREFIX=`$PYTHON -c "import sys; print sys.prefix"`
 colliera> PYTHON_EXEC_PREFIX=`$PYTHON -c "import sys; print sys.exec_prefix"`

Unfortunately, that would break DESTDIR installs and also
prevent installations with @prefix@ overridden at make-time; two
idioms used to build binary packages, and whose support is
required by the GNU standards.

 colliera> now, an obvious solution is to configure the package
 colliera> with --prefix=/usr but this means that all the
 colliera> executables/libraries in this package will land up
 colliera> under /usr (and not /usr/local).

I agree it would be nice for the user to be able to tune these
directories at ./configure-time.  I'll try to look into this.
We do the same for Emacs lisp files (installed in /usr/local
even if emacs is in /usr), but at least there is a --lispdir=
option to override the directory.

-- 
Alexandre Duret-Lutz