[Distutils] (final?) automake related questions

[Greg Ward]

[I mis-speak myself]
> I like exec because most (all?) of the Python stuff under
> exec_prefix isn't executable, but it is platform-specific (shared
> objects for the most part).

[Andrew catches me]
> Did you mean you "like" or "don't like"?  I personally do not
> like it for that reason.  Still, that's the way Python does it
> which is why I (eventually) chose that name.

Ooops!  I *don't like* using "execlib" for "platform-specific library
directory".  I now see that that usage descends from Autoconf's "exec
prefix" notion, which is pretty well established by now.  However, in
switching from the Autoconf point-of-view ("let's build this Python
thing, which is basically a C program with some ancillary files, some of
which are platform-specific and some not") to the Distutils POV ("let's
build this bundle of modules to add to the Python library; some of the
files to install are pure Python modules, and some are platform-specific
extension modules"), a change of terminology is in order.

The convention in Python-land seems to be "plat" for "platform" (as
opposed to "arch" for "architecture" -- six of one, half a dozen of the
other!), so I went with "install_platlib" and "install_site_platlib" as
the directories to which platform-specific files will be installed.
(Most distributions will install to install_site*; only distributions
that are part of the standard library will use the "install_*"
directories.  The idea here is that some distribution -- say, the
Distutils itself -- will be part of the standard library, but might be
released more frequently than Python itself.)

> I would shy away from using 'lib'.  Automake expects 'lib_' as
> a special prefix (for files which are installed into the standard
> library directory).  Also, 'LIB' is the prefix for the suffixes
> (like 'LIBS', 'LIBTOOL', 'LIBADD', ...) related to the
> construction of static and shared libraries.  I worry that
> those two uses (variables for Python libraries and "real"
> libraries) should have names which are more distinct.
> 
> This is important for us because we're going to use the same
> system for all of our code (C, C++, Python) so I want to make
> things pretty clear.

That makes sense for you in the Automake context.  If Automake/Autoconf
think that "lib" is a platform-specific C library (libfoo.a, libfoo.so),
then it makes sense for you to stick to that narrow definition.
However, we all know perfectly well that foo.py is a Python library (or
part of one), and Python is just as good as C -- so why come up with
some other word than library?

So I think your scheme makes sense for Automake, but I would still
consider changing "exec" to "plat" at some point if it makes sense and
Automake doesn't whine.  And I think my scheme makes sense for a
Python-specific build/distribute/install mechanism, so I'm gonna stick
with what I've got.

>   However, do you distinguish between files which are placed
> under Python's lib/ directory and files which are placed, say,
> in /usr/local/lib/ ?  I could make up an example, if you
> want, though since I cannot think of anything but contrived
> ones, I don't think it's an urgent need.  Still, it may be
> useful that such an option is available.

That's quite possible for a Python application that has configuration
files and such.  Note that the Distutils "prefix" is still (eg.)
/usr/local -- it's just Python's prefix.  So there's no problem in a
particular application (or even module distribution, although it's
probably bad practice for a programming library to have config files)
using that to put its stuff in /usr/local/lib.  If there's a demand for
it, Distutils could probably have direct support for installing
"ancillary files", but I don't see that being an issue until we truly
support Python *applications* (as opposed to libraries).

        Greg
-- 
Greg Ward - software developer                    gward@cnri.reston.va.us
Corporation for National Research Initiatives    
1895 Preston White Drive                           voice: +1-703-620-8990
Reston, Virginia, USA  20191-5434                    fax: +1-703-620-0913