On Oct 3, 2005, at 1:17 PM, Ronald Oussoren wrote:
I'd guess that nobody has needed this functionality badly enough to volunteer extending distutils :-).
Since I do need it, I've been working on build_shlib and
install_shlib distutils commands for building and installing shared
libraries that extensions can link to. The commands are working on
Linux, OS X 10.4, and (sort-of) on SGI Irix.
I have a few questions:
Why does UnixCCompiler._compile spawn self.compiler_so? This seems
to be wrong (even for regular extensions). It works satisfactorily
when the C compiler can also handle C++ code, but fails when the C
and C++ compilers are separate, as when using the SGI MIPSpro
compiler. Shouldn't _compile use CCompiler.detect_language and spawn
compiler_cxx if necessary? (I think this is a problem not just with
build_shlib, but with build_ext and build_clib as well.)
py2app is the only other package I know that adds commands to
distutils. It modifies the Distribution class like this: class Distribution(distutils.dist.Distribution): def __init__(self, attrs): etc... distutils.dist.Distribution.__init__(self, attrs) distutils.core.Distribution = Distribution The problem with this is that any other package (such as mine) that
also modifies Distribution will either overwrite or be overwritten by
the py2app modifications. Shouldn't Distribution be modified like this: oldDist = distutils.dist.Distribution class Distribution(oldDist): def __init__(self, attrs): etc... oldDist.__init__(self, attrs) distutils.dist.Distribution = Distribution Then if two different packages both modify the same class, the
__init__ calls are chained together.
What's the best way of testing my code on a variety of platforms? I
only have easy access to a few different architectures and operating
systems. There are spots in the code where I've pretty much just had
to guess at what to do, based on other parts of distutils.
Would someone who's more familiar with distutils than I am like to
take a look at what I've done and give me some feedback? I can
either e-mail the files or put them on a web site. They're not
really ready for release yet, I don't think.
-- EMail: email@example.com Phone: (301)
975-5423 -- -- WWW: http://math.nist.gov/mcsd/Staff/SLanger/ Fax: (301)
990-4127 -- -- Mail: NIST; 100 Bureau Drive -- Stop 8910; Gaithersburg, Md
-- "I don't think this will work. That's why it's
science." -- -- Naomi Langer, 17 Feb