Quoth John Skaller, on 20 December 1998:
> I think you are missing the point here: if the configuration
> doesn't work, the client has NO CHOICE but to edit it.
> And if it isn't editable, the client has NO CHOICE, full stop.
> Now, you don't want to leave the client without options, in
> case something as complex as configuring a compiler fails, do you?
John -- I don't think not being able to edit sysconfig leaves people out
in the cold. Fred's current implementation is, in fact, quite
non-editable, as it scans Makefile and friends as late as possible
(ie. when sysconfig is itself imported).
However, that doesn't preclude the ability to override Makefile/config.h
settings at module build or install time. I believe my proposed user
interface for the distutils touches on this: we could just have command
line options intercepted by the appropriate distutils module to override
its default behaviour (where the default is usually dictated by the
Python config info harvested by sysconfig).
Eg. if you know bloody well what you're doing and are willing to take
the responsibility for compiling an extension module differently from how
Python was compiled:
./setup.py build -cc gcc -cflags -O3 -cppflags '-DSOME_MACRO'
...or something along those lines. It's possible to consider a way to
make those override preferences permanent for a site and/or user, but
that's a detail. There's certainly no need to go editing a generated
sysconfig (if indeed we end up moving away from Fred's current
implementation and towards that model), or the Makefile/config.h/Setup
in $(execprefix)/lib/python$(version)/config.
And again, quoth John Skaller, on 20 December 1998:
> BTW: It is _also_ recommended to have the ability
> to generate applications, not just Python modules. The 'make'
> system know how to do that too, and it is useful for extending
> Python with 'shell' tools.
I alluded to that in a post a couple of days ago; my opinion is *still*
that we should concentrate on module distribution, and hopefully
application distribution will emerge as a natural application/extension
of module distribution.
Then of course, there's also Mark Hammond's thread on freeze-as-
distribution-mechanism. Strikes me as a neat idea, especially for
distributing full-blown Python applications. I really must play around
with freeze before I can have any sort of informed opinion there,
though.
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