Build bugs in Python 2.2.1?

[Jonathan Hogg]

On 12/8/2002 14:14, in article lkvg6gmddn.fsf at pc150.maths.bris.ac.uk,
"Michael Hudson" <mwh at python.net> wrote:

> Please don't get discouraged from working on distutils or Python's
> build process!  But please also understand that there is a reason for
> most of the extant stuff, and as Martin says, vague comments along the
> lines of "it would be nice if ..." are not really helpful.

*sigh*

If I have appeared vague before, I'm sorry. I haven't come here with a
solution because I don't have one. I tried to demonstrate where and why I
think there is a problem and suggest a possible idea for a solution.

In the interests of not seeming like a spoiled child (I was pretty tired
last night when I gave up), I'll explain one more time. If someone doesn't
understand or sees that I've missed something, please say so. I'm not trying
to call-for-the-head-of distutils. It just doesn't work for me and here's
why:

One of my day jobs is managing multi-platform UNIX sites. I use a system
called Arusha for doing so. This allows me to manage packages by noting what
kind of package it is and any important differences or exceptions that
should be taken into account.

For most of the autoconf-style packages I install I can just specify
something along the lines of:

    <prototype team="." name="GNU"/>

and it works. It gets built from source on each platform, installed,
deployed onto all of the systems, and revealed into the users' namespace.
For packages that have dependencies, for instance on OpenSSL, I can usually
add a simple addition to this specifying the dependency and adding the
necessary argument to allow configure to enable/find it:

    <configure>
        <constraint>
            <dependency type="normal" name="openssl" method="deploy"/>
        </constraint>
        <param name="ssldir">!field.dependencyDeployDir('openssl')</param>
        <param name="configure_args">--with-ssl-dir=@param:ssldir@</param>
    </configure>

This translates into an underlying shell script something along the lines
of:

    CFLAGS=... LDFLAGS=... \
    ./configure --prefix=... --with-ssl-dir=/._ark-deploy/openssl--0.96e

and that's all I need to do to make it work.

Unfortunately, life is not so simple with Python, because while having a
configure front-end, the Python modules build process cannot be controlled
with configure. I can't pass in the necessary CFLAGS and LDFLAGS to enable
the SSL module to be built correctly either, because the flags are ignored
by setup.py.

To compile the SSL module I have to edit Modules/Setup. This sounds fine to
most people, but the only way to do that in a repeatable way is to generate
a patch. Since the patch file will vary depending on which version of
OpenSSL I compile against (I have to be able to maintain multiple different
versions) and possibly which platform I'm compiling for, the patch must be
generated programmatically. The patch also varies depending on the version
of Python so I have to maintain multiple patch templates.

If someone can point out the blindingly obvious thing I've missed that will
make all this horror go away, then please let me know.

It's quite funny in a way because Arusha is written in Python, and that's
because I sold it to the main guy behind Arusha as being a fantastic
language. And yet, Python is the hardest language to build using it ;-)

Jonathan