[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