As I've been going on about, I've got the changes made so that
GNU automake supports Python. Because it is the FSF, I had to
sign paperwork to disclaim copyright interest in our contributions
before they would accept it. I mailed them in today.
Thus, I've been touching up my changes before submitting them.
I wanted to make sure I was using a sensible (or at least
reasonable) set of names before I did that.
Here are the names for which I am uncertain:
This is the value
sys.prefix + "/python" + sys.version[:3] + "/site-packages"
It is the location where platform independent modules should
be installed. It can be overridden on the configure line with
the parameter --with-python-site=DIR
automake defines the variable PACKAGE, which I am taking also
as the module name (nothing unusual about that, I hope).
This is the value
sys.exec_prefix + "/python" + sys.version[:3] + "/site-packages"
It can be overridded on the configure line with the parameter
I played around with a few names. These seem to make sense to
me (eg, PYTHON_SITE_EXEC is better than PYTHON_SITE_SHARED which I
had). I cannot find if the standard Python libraries refer to
these directories in some other fashion. The closest I can find
is "site.py" which combines the first and last directory names
directly into "sitedirs".
*** question 1: Do these names make sense to others?
o I added a new m4 macro for "aclocal" called "AM_CHECK_PYTHON".
This is the command which goes in "configure.in" to tell autoconf
that it needs to generate Python information.
The macro takes one optional parameter. If the value is "classes"
the Python files in the package are installed directly in
PYTHON_SITE. If the value is "module" then they are installed
into PYTHON_SITE_PACKAGE. The installation directory name is
stored in the variable PYTHON_SITE_INSTALL.
If you have the file "Vector.py" in the autoconf package "vecmath"
with the PYTHON_SITE set to /usr/local/lib/python1.5/site-packages
AM_CHECK_PYTHON(module) puts it in
AM_CHECK_PYTHON(classes) puts it in
*** question 2: Should it be "classes" or something else?
Since there's no existing python command-line program to compile
a *single* python program (as compared to compileall which
compiles, well, all :), I'm using the following in the Makefile
(the value of PYTHON is the full location of the python executable
and was found during the configure step):
PYTHON_COMPILE_CMD = "-c 'import py_compile, sys; \
PYTHON_OCOMPILE = $(PYTHON) $(PYTHON_COMPILE_CMD)
PYTHON_OCOMPILE = $(PYTHON) -c $(PYTHON_COMPILE_CMD)
@echo "Compiling python file $< "
@echo "Compiling python file $< (optimized)"
The idea is that I hope distutils will have a command-line way to
do this, so I can replace all that with:
@$(PYTHON) $pythondir/distutils/compile.pr $<
@$(PYTHON) -O $pythondir/distutils/compile.py $<
(I hide the actual compile with @ because otherwise you just see
the full "import .... argv)" which is hard to read. By having
a program to byte compile a file directly I can get rid of the noise.)
*** question 3: Can distutils provide this sort of service?
*** question 4: Anyone interested in getting the latest CVS
distribution of automake (after I get the changes in) to play^U
test things out?
To help out, I'm also working on documentation so people can use
it without reading the full automake documentation (which has a
strong emphasis on building C programs). Not suprisingly, this
email will be a hefty part of said documentation :)
Here's the list of other definitions created by configure.in.
I cannot see how there's any real problem with these names, but
who knows ....
PYTHON = full name of the python executable
PYTHON_PREFIX = sys.prefix
PYTHON_EXEC_PREFIX = sys.exec_prefix
PYTHON_VERSION = sys.version
PYTHON_PLATFORM = sys.platform
pythondir = sys.prefix + "/python" + sys.version[:3]