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. Thanks, Steve -- -- EMail: stephen.langer@nist.gov 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 20899-8910 -- -- "I don't think this will work. That's why it's science." -- -- Naomi Langer, 17 Feb 2003 --