[Distutils] Responses to proposal
Wed, 20 Jan 1999 17:08:43 +0100
Greg Ward wrote:
> [Fred says the need for application-specific command-line options is not
> 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.
I think dependencies on external packages should be abstracted as much
as possible. Otherwise extension/application writers still end up having
to write specific configuration stuff for each platform Python runs on,
which wasn't what we wanted.
Perhaps we can distribute 'external package info files' for common
external packages, describing how this package works on various
platforms (where the files are, what they're called, how to link to
These external package info files should be independent of the Setup
scripts of specific applications. This way someone else than the
extension writer can maintain them, and you only need to do write an
information file once for each external resource. In the end the writers
of libraries may start making these info files by themselves. :)
> 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.
And I think options file versus command line options warrants some more
discussion, too. Not a whole flamewar, but I wouldn't like to settle on
a vast slew of command line options if a nicely commented options file
can be used instead. Obviously I'm
biased more towards options files, see my earlier discussion in the
> [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
Actually John Skaller and I and others had some dialogue on this topic
on this list some time ago. John posted some relevant code, I posted
some comments on this (if I didn't reply to sender instead of to list,
as I'm about to do now, but I caught myself just in time :) If you want
I can probably drag it up in my mailbox. I also posted an early design
of what I thought it should look like, and what the requirements are.