[Distutils] (final?) automake related questions

Andrew Dalke dalke@bioreason.com
Wed, 07 Apr 1999 14:35:41 -0700


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