Build bugs in Python 2.2.1?

Jonathan Hogg jonathan at
Sun Aug 11 22:04:40 CEST 2002

On 11/8/2002 18:39, in article m3it2hjnwe.fsf at,
"Martin v. Loewis" <martin at> wrote:

> Jonathan Hogg <jonathan at> writes:
>> I consider removing the UNIX-specific magic from *would* be an
>> improvement.
> That might be the case - it depends on the precise details on how this
> change is implemented.

Ahhh, the devil is in the details...

As simply as possible in my book. The bare minimum changes for me would be a
small amount of logic in configure which would enable and setup the few
modules with external library dependencies (ssl, dbm, expat, etc.) if the
appropriate --with-* flags are set. If they aren't then it could simply fall
back on the existing functionality. That would be enough to enable me to
integrate the building of Python into my framework simply.

In the interests of not adding more special cases, I'd prefer that the whole
procedure of configuring modules on UNIX is revisited. God knows, autoconf
isn't pretty, but it is well maintained and very capable. When it comes to
determining what is available on a particular UNIX platform, isn't
going to come close.

>> An improvement for me would be being able to do:
>>     % CFLAGS=... LDFLAGS=... \
>>       ./configure --with-ssl-dir=... --with-dbm-dir=...
>> and have everything compiled with consistent compiler flags and have the
>> corresponding modules compiled against the specified libraries.
> You have to be more precise than that. How exactly do you expect the
> setting of CFLAGS and LDFLAGS to be used? Completely ignoring them
> throughout would also be "consistent".

I would expect them to be used wherever something is compiled or linked -
that is the generally accepted purpose of setting them.

> In anycase, on the matter of LDFLAGS, please review
> atid=305470
> and add any comments you have to this report.

I'll try to get some time to look at this patch.

> I doubt many people would consider the addition of tons of --with-
> flags as an improvement.

Many people wouldn't have to use them. However, when you need to specify
exactly where to find the dependencies, this is the best way. As I've said
before, editing a config file is a poor solution. Made even more poor if you
use a build system that manages dependencies programmatically. Passing in
the appropriate --with-* options is easy, generating a custom patch file to
apply against Modules/Setup is not.

>> I don't see another clean way to communicate such build information from
>> configure to than via Modules/Setup.conf.
> configure could (and does) record things in Makefile.pre.

Is this used by distutils in the building of modules?


More information about the Python-list mailing list