On 21 September 2000, Uche Ogbuji said:
We just found out that this is indeed not the problem. The problem was that RPM wasn't getting the right lists of installed files, so it was getting confused about where things were.
...which probably has something to do with your highly customized build process...
You ain't seen nothing yet! We fixed a whole bunch of our additional packaging problems with more distutils subclassing. Check out
...OK, I'll download this one once I've got SWIG installed. *Then* I'll look into your sordid mess!
We'd love to hear any feedback about our distutils efforts. We hardly thought we were doing anything extraordinary, but distutils does seem to have several limitations as is that we had to sub-class to get around. Maybe we were trying too hard in some cases.
No build system can cover every possibility out of the box, that's why they have to be extensible. Distutils covers pure Python modules, vanilla Python extensions, SWIGged Python extensions, and C libraries that are statically linked into Python extensions pretty nicely (if I do say so myself). Anything outside of that box and you've got to write custom code.
(The theory was that Python programmers would prefer to write such custom code in Python, rather than cobbling together a nightmarish mix of m4, shell, and make that a traditional Autoconf/Automake system implies -- and of course, doing it all in Python makes it portable to other platforms. In practice, it turns out that extending a large object framework requires a bit more in-depth knowledge than cranking out a few more Makefile targets. Well, if nothing else it's an interesting experiment, and I think it's fairly successful.)
Anyways, I already got some feedback from Mike about refactoring the install_lib command for easier extensibility -- and in fact I'm about to checkin a change that should help there. See my next post.