Beat Bolli <address@hidden> writes:
The help for get_python_lib() says:
Help on function get_python_lib in module distutils.sysconfig:
get_python_lib(plat_specific=0, standard_lib=0, prefix=None)
Return the directory containing the Python library (standard or
site additions).
If 'plat_specific' is true, return the directory containing
platform-specific modules, i.e. any module from a
non-pure-Python
module distribution; otherwise, return the platform-shared
library
directory. If 'standard_lib' is true, return the directory
containing standard Python library modules; otherwise, return
the
directory for site-specific modules.
Hmm, I'm having a hard time following that documenation.
plat_specific would seem to be about having a directory for python
modules that are specific to this cpu architecture vs modules that
are
just in python and therefore arch-independent. This seems to be the
same notion as /usr/lib vs /usr/share. But looking on my system, I
see
/usr/pkg/lib/python2.7/plat-netbsd6
so that makes me think that the sharing is about OS rather than cpu.
But the file
/usr/pkg/lib/python2.7/site-packages/gps/packet.so
is compiled for not only NetBSD 6 but i386. So this whole
plat_specific
notion seems boggling.
/usr/pkg/lib/python2.7/site-packages # standard_lib false
/usr/pkg/lib/python2.7/ # standard_lib true
If 'prefix' is supplied, use it instead of sys.prefix or
sys.exec_prefix -- i.e., ignore 'plat_specific'.
Passing prefix='/usr/local' yields the correct path under Linux, but
ignores the plat_specific argument. Would this hurt on other
platforms?
I cannot understand how the before and after "ie"" parts are the
same.
It seems to blur changing prefix and also whether or not to use the
plat-$uname subdir.
The conclusion I've more or less come to over the years is that
building python in one prefix and a package in another is trouble,
and
there are two ways to cope:
Teach python about the other prefix, and have it look there, or
use
PYTHONPATH. . Have packages put python libs in their own prefix,
but parallel structure to how it would be in python's prefix.
Install the python bits in python's prefix instead of the
package's
prefix. This is odd because it writes outside of ${prefix}, but
then
python finds the bits.
Neither way is really satisfactory. But they end up being the same
with
matching prefixes, which is the case I really care about. I prefer
to
have python bits in gpsd's prefix by default, which is what your
patch
does. So it looks good to me.