[Distutils] Hacks and bugs for distutilizing wxPython
Sat Oct 14 02:59:09 2000
Looks like I've got wxPython building with Distutils now on win32, Linux and
Solaris. I thought I'd pass along the things I had to hack around so maybe
some official solutions could be put into Distutils 1.1...
1. As mentioned previously I need to pass -I flags to the resource compiler
for my .rc file. I just hacked it to use the same flags passed to the C
compiler but it might make sense to do it with a new attribute of Extension.
2. My secondary extensions need to link with the import lib produced from
building the first extension. The default location of this file is dynamic
based on the python version, debug status, and also the relative path to the
first source file. Since there was no reliable way to determine before
setup() was called where that directory would be I hacked it to just use a
fixed location for the implib (build\ilib\).
3. I implemented these two hacks by deriving from MSCVCompiler and replacing
the whole compile and link methods, each with only a one or two line change.
It would be nice if they were more modular so derived classes could just
override little bits here and there instead of huge methods.
4. I noticed this one on win32 but it may be a general problem. If relative
path names containing '..' are used for extension source files then the
objects can be placed in odd locations, possibly not even under ./build.
For example, '../../wx/contrib/src/stc/stc.cpp' will have its object file
put in build\temp.win32-1.5\Release\../../wx/contrib/src/stc/stc.obj which
defeats the purpose of having the protection of temp.win32-1.5\Release!
Related to this, if a full path is given to a source file, then the object
will be put in the same directory as the source. I think object files
should always be put under the build dir.
5. On my Linux system (RH 6.1, RPM 3.0.3) bdist_rpm failed with this
Could not open
because bdist_rpm didn't make the i386 directory.
6. Why is -g used by the compiler when --debug is not given to distutils?
7. It would be nice to be able to override CC, LDSAHRED, etc. (by setting
environment variables or something) instead of just blindly taking them from
Python's Makefile. For example I would like to be able to use "gcc -G"
instead of the default (with Py-1.5.2) of "ld -G" on Solaris so that the
static C++ objects will actually get initialized instead of being full of
garbage and causing the application to segfault.
8. Neither the SWIG support in 1.0 nor the recently contributed patches
would meet my needs so I rolled my own. It's not integrated with build_ext
but is run before setup() while I am constructing my Extension objects, and
the list of generated sources is returned so it can be used to build the
Extension object. It's very specific to my needs but others may find it
useful too. I was able to reuse a lot of utility functions from distutils
so much of the behaviour is similar to the way the rest of it works.
You can see my setup.py and support files at:
It may be educational to take a look at it, even if it's just to point out
the mistakes that a Distutils newbie like me makes! <grin> BTW, does
anybody else have a 436 line setup.py? (Plus a coulple hundred for my
MSVCCompiler hacks and other helper functions.)
http://wxPython.org Java give you jitters?
http://wxPROs.com Relax with wxPython!