[Distutils] Packages with C extensions

[Perry A. Stoll]

> M.-A. Lemburg <mal@lemburg.com> writes:


>[Problem with dynamic extensions in packages being platform dependent]
>
>I haven't followed the thread too closely, but was alarmed by
>the recent proposals of splitting .so files out of the "normal"
>package distribution under a separate dir tree.

Fair enough. There's the the GNU configure view of life, where $prefix and
$exec_prefix are separate directories, and there is the perl view of life
 $PERL_ARCHLIB is usually a subdirectory of the install directory). M.A.
prefers the perl-ish approach. Fine with me, as long as we do it explicitly.

> (you can't have two top-level packages with the same name
>on the path: only the first one on the path will be used).


That's only because that's how it's done today. Just a matter of some
code...(and the thought and design behind it).

>  [ snipped scheme for having packages do the platform specific import ]


I'd rather not burden the package writer. I think it's better to include the
batteries for this one.

>  [recommendation that you just have a different install dir for each
platform ]
> Disk space is no argument nowadays

Ease of maintenance is the overriding argument here. The .py files are the
same for all platforms so why do I want different copies of those files when
I have python install for three platforms?

> its likely that different platforms need different Setup files anyway.


But that's a platform dependent file which goes in the $INSTALL_ARCHLIB.

In short, I think we need to get this infrastructure into Python itself to
ease the creation of package authors. But then I'm probably preaching to the
choir.

-Perry