[Distutils] non-"standard" compilers...

[Phillip J. Eby]

At 12:41 PM 5/27/2005 -0400, Nicholas Bastin wrote:
>On 5/27/05, Phillip J. Eby <pje at telecommunity.com> wrote:
> > At 12:15 PM 5/27/2005 -0400, Nicholas Bastin wrote:
> > >Also, I'm assuming this is only true on unix?  Win32 seems to pick
> > >MSVC no matter what (and complain a lot if you don't have it).
> >
> > That's because MSVC is the only supported compiler for Python on that
> > platform.  There has been some work on supporting the MinGW compiler, and
> > the MinGW compiler can be used to build extensions that work on Windows,
> > but nobody has done any work on supporting any other compilers that I 
> know of.
>
>The Intel C++ compiler works perfectly well (we build and ship using
>this compiler).  However, because we do this, we can't use any
>distutils-distributed extension modules, because they complain that we
>don't have the .NET runtime or some such.  I usually just try to
>construct makefiles for the extension modules in each package, and
>that works reasonably well for most extensions.

Perhaps you should consider contributing a Compiler class to the distutils 
to resolve this.

Also, I'm not sure if you know about the distutils.cfg file, but once you 
have a compiler class set up, you can make it the default with the 
appropriate entries in that configuration file, so that you don't even need 
to specify the -c/--compiler option.


>Also, does distutils support the notion of installation a 'FAT'
>distribution?  We also have to tear each install apart to put the .py
>files in a platform independent place, and the .pyd's in a
>platform-specific location, which usually involves a lot of magic
>tricks when the .pyd's are imported as part of a package.

There are --install-platlib and --install-purelib options that can be set 
to separate the two, but recombining them is tricky, as you point out.

You might be interested in the Python Eggs project, which allows multiple 
platforms (and multiple versions) of the same library to live side-by-side 
in site-packages or elsewhere, but get selected at runtime.  You do, 
however, have to invoke some code at application startup to request 
activation of the desired library, but this can be simple as:

     from pkg_resources import require
     require("MyApplication")

If you've defined an egg for MyApplication that has a file listing the 
other libraries and versions that it depends on.  Platform selection is 
more or less automatic, although it's based currently on the distutils' 
idea of what a "platform" is, so that may or may not work for your needs.