Build bugs in Python 2.2.1?
Martin v. Loewis
martin at v.loewis.de
Mon Aug 12 08:08:18 CEST 2002
"Steve Holden" <sholden at holdenweb.com> writes:
> 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?
That depends on the questions you want to ask. Questions that can be
likely answered in a portable way are
- does a certain header file exist?
- does a certain library exist?
autoconf uses a number of host utilities to answer these questions
(/usr/bin/test, /usr/bin/ls, etc) to answer these questions, but a
Python script can answer them without escaping to command line
Questions that require you to invoke the compiler are
- does a library provide a certain symbol?
That question can be answered without invoking the compiler on some
systems, but invoking the compiler is a quite universal way - assuming
that the compiler will report an error when the program fails to link.
It might be tricky to invoke the compiler, since some compilers are
not designed to be invoked by a program - however, distutils has
already solved this problem.
Questions that require to run a program are
- does a library function behave correctly (for some purpose)
That question is cannot be answered in a cross-compilation
environment, since you usually cannot run binaries for the target.
autoconf "solves" this problem by using design-time defaults, and
offering the user to edit files (config.h). Python has the same
> 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.
That's why I think proposing specific patches is the right way to go.
Then people can review it, and comment on what would break under such
More information about the Python-list