On Tuesday 29 June 2004 11:28, Hans-Peter Jansen wrote: > On Tuesday 29 June 2004 11:56, Joachim Werner wrote: > > As expected, the current official PyKDE sources don't compile here > > either. But I think it doesn't make too much sense to fix them as > > the separate PyKDE package will be dropped and made obsolete by the > > new KDE bindings package soon. > > Usually, all it takes are a few strategic links: > > for i in $(find sip -name \*-kde323.diff); do > o=$(echo $i | sed "s|kde323|kde329|g") > ln -s $(basename $i) $o > done > ln -s kde323 extra/kde329 > > Jim, it might be worth to adapt this logically to configure.py, > together with a warning message, that if this build succeed, no new > methods of the unsupported version will be generated. I might look > into it, if you like..
Yeah - that's what I'm thinking of. I have configure.py set up right now (in the upcoming snapshot) to treat versions >= 3.2.90 as 3.3.0, but I also have added the extra/kde330 directory/files and *-kde330.diff files as well. I could just adjust configure.py to point versions > "latest released" to the corresponding latest extra/kde* and diff files provided, as in the shell script above. It won't work however when binary compatibility is broken in the new version (eg some KDE3.1.4/KStartupInfo and other cases), or when files/classes are deleted from KDE or moved to another h file (both linking and resolving h files - eg KAccelAction (?) subclasses in 3.2.0). My preferred solution is to release timely snapshots, but the problem there is testing. I don't want to spend more time building KDE than I spend maintaining PyKDE. I'll give it some thought - I'm leaning towards snapshots right now as opposed to configure.py patches that won't always work, even if that mean having to build KDE (shudder). Jim _______________________________________________ PyKDE mailing list [EMAIL PROTECTED] http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
