Re: [gpsd-dev] [PATCH] Build: add the configuration variable python_libdir.

[Greg Troxel]

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.

When you say passing /usr/local and  "correct path", do you mean

  ${gpsd_prefix}/lib/python2.7/site-packages

instead of

  ${python_prefix}/lib/python2.7/site-packages

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

pgp1b2tGqx5Yv.pgp
Description: PGP signature