Build bugs in Python 2.2.1?

[Steve Holden]

"Martin v. Loewis" <martin at v.loewis.de> wrote in message
news:m33ctljfgv.fsf at mira.informatik.hu-berlin.de...
> Jonathan Hogg <jonathan at onegoodidea.com> writes:
>
> > 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.
>
> Feel free to try. Experience has shown that this is *not* simple. In
> particular, setting up bsddb is a nightmare.
>
The generality of the build process is such that people such as myself (with
experience in Linux, Windows and Solaris) can easily overlook problems
specific to other platforms. This is one of the reasons why I've been
lurking on this thread rather than contributing: I have little to say in the
face of such well-informed comment.

> Please use the latest CVS, though: expat has no external library
> dependencies.
>
> > 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.
>
> Now I don't understand: What do you mean by "enable and setup"?
> I.e. what is the precise set of files written, options added, and so
> on? If that means "compute the set of compiler options needed to build
> these modules", then how do you use that information?
>
> > 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, setup.py
isn't
> > going to come close.
>
> That is only because distutils doesn't provide good support for that.
>
Well, maybe the real questions are "why can't distutils use autoconf on Unix
platforms" and "what would other platforms use int he absence of autoconf?".
However, I'm very aware that the current position has come about as a result
of many specifics, and that generalities aren't likely to be productive
here.

> Remember, all that autoconf does is to generate a shell script. All
> that the shell script does is to invoke some tools on the
> system. There is nothing that a Python script could not do, either.
>
And, obviously, if the Python script is portable across all configured
paltforms this is clearly to be preferred. Do the tools actually exist on
all the platforms Python supports, though? If not, what can we use in their
place? And would it be more appropriate to use these on the platforms that
support autoconf too?

I have to say that a breif glance at the "autoconf" man page is quite enough
ot convinve me that it's oversimplified. "info autroconf", however, appears
to need at least a week to absorb. This underlines the difficult nature of
the problems to be solved.

> > > 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 addition or instead of the default, or by some other combining
> algorithm (if so, which one)?
>
> > > configure could (and does) record things in Makefile.pre.
> >
> > Is this used by distutils in the building of modules?
>
> Certainly: distutils reads Makefile to find out variable settings.
>
> There is little point in discussing such things in the abstract. You
> really have to study the current procedure in detail to understand why
> things are done the way they are done.

I think from my own studies that you actually also need a better
understanding of history than an easily-available document currently
provides. Python-install wisdom is hard to come by.

mostly-because-doing-it-and-documenting-it-are-disjoint-ly y'rs  - steve
-----------------------------------------------------------------------
Steve Holden                                 http://www.holdenweb.com/
Python Web Programming                http://pydish.holdenweb.com/pwp/
-----------------------------------------------------------------------