[Distutils] (final?) automake related questions
Wed, 14 Apr 1999 11:24:58 -0400
[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 Ward - software developer email@example.com
Corporation for National Research Initiatives
1895 Preston White Drive voice: +1-703-620-8990
Reston, Virginia, USA 20191-5434 fax: +1-703-620-0913