Thanks for the comments, Greg.
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).
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.
install_site_lib install_site_platlib
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.
And I think you would rename my install_site_lib and install_site_platlib to install_site and install_site_exec.
Yep :) Though if it makes sense, I think people can live with the differences. 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.
I notice that both schemes have no notion of /usr/local/lib/site-python -- this is a feature, right?
Yes, based on Fred Drake's comment in this list that this directory is to be considered deprecated. Though for the automake mods it can be overridden with ./configure --with-python-site=/usr/local/lib/site-python This is important for us because we install all of our internally developed packages in /br/stable/lib/python1.5/ while externally developed ones are in the usual /usr/local/lib/python1.5/site-packages.
Umm, are you talking about "package" in the Python sense of a special directory full of modules, or in the general sense of a discrete chunk of software to distribute?
Indeed, I am confused by its definition in the Python world. However, in this case I use "PACKAGE" because that's the word specifically used by automake, and automake uses it in the general sense of the world. PYTHON_SITE_PACKAGE is the combination of (my) "PYTHON_SITE" directory and (automake's) "PACKAGE" name. Also, someone can override PYTHON_SITE_PACKAGE in the configure.in file to be anywhere they want it to be. My code just sets the default and uses that variable wherever it might be useful.
Anyways, whichever it is, it's not necessarily the same as the "module name". Both packages (Python meaning) and packages (general meaning) may have many modules!
Yes, just like in C you can have a single source distribution which includes several programs, each of which installs to different places. Automake supports this; you can override almost everything as long as you are cleaverer in how you use it. I think what I've added is able to support having a distribution with several Python module distributions. Though I haven't tested it, because we're operating under the "one distribution - one python package" development philosophy.
The name of the distribution must be specified in setup.py.
The automake way lets you define/override information in the configure.in file(s)
I assume you mean the one-line compilation business. I would argue against Distutils providing a one-line compiler for use in Makefiles: if you have Distutils, you don't *need* a Makefile! (At least not for your Python components.)
It was either that or petition for an option to 'compileall' to take a list of files to compile rather than a directory name. We (Bioreason) still need a Makefile since it drives things not part of the Makefile, like tagging everything in CVS with the current build tag, updating the build number, removing .pyo and .pyc files with "make clean", driving the building of the documentation from LaTex (or pod), running the regression tests, etc.
pythondir = sys.prefix + "/python" + sys.version[:3]
Again, my inclination would be to make explicit the fact that this is the library directory, eg. "pythonlibdir".
This variable name also is an automake-ism. The existance of a "pythondir" tells automake that targets like "python-clean" exist. It also says that "python_PYTHON" contains the list of Python files.
You can singly-quote those [Perl] strings
Yeah. There again I was sticking with the existing automake code, which uses double quotes for the equivalent section related to emacs lisp compilation. Perhaps it was a hobgoblin consistancy. Andrew dalke@bioreason.com