[Distutils] Responses to proposal

[Greg Ward]

[Fred says the need for application-specific command-line options is not
clear]

My impetus for this was the need for specific module distributions to be
told where to go looking for external C libraries.  For instance, the
setup.py for zlib would need to know where to find zlib.h and libz.a --
that is, how to generate a -I option for compiling the extension, and a
-L option for linking it (modulo the usual Unixisms).  Likewise, tkinter
needs to be told where to find the Tcl and Tk headers and libraries.

Granted, there's already a standard way of doing this: the Setup file.
Perhaps we should preserve the Setup file, or perhaps we should mutate
it into a Distutils-specific 'options' file as per Martijn's suggestion
for replacing my command-line options.

However, let's not limit ourselves to "where's this header file, where's
that library?" questions: lots of modules could have configuration
options that the builder might want to supply at build time.  And keep
in mind that ultimately we want to be able to write setup.py for a whole
Python *applications*, which almost certainly will have configuration
options: where to put temporary files? permanent data files?
installation directory? etc.

[Martijn Faassen berates me for forgetting about abstract compiler classes]
> You don't expose Unixish C compilation variables to the user at all,
> perhaps? At least in principle. In practice you'd still allow
> modification, but it shouldn't be *necessary* to look at these or even
> know about them, even to write a C extension. (unless you're on some new
> platform)

Duh, you're right.  I had *Programming Perl* sitting on my lap and open
to the section on MakeMaker as I wrote that part of the design proposal.
(Mainly I wanted to be sure I didn't forget anything obvious.)  Small
wonder a few Unixisms creeped in!

Anyways, this raises the broader question: how should the class(es) that
abstract compilation and linking behave?  I'll try to come up with a few
ideas and post them separately.  (Arg, really must look at Interscript's
compilation stuff... presumably John has already thought through this
stuff!)

        Greg
-- 
Greg Ward - software developer                    gward@cnri.reston.va.us
Corporation for National Research Initiatives    
1895 Preston White Drive                      voice: +1-703-620-8990 x287
Reston, Virginia, USA  20191-5434               fax: +1-703-620-0913