On Saturday 09 September 2006 04:42, Simon Edwards wrote: > On Friday 08 September 2006 23:42, David Boddie wrote: > > On Friday 08 September 2006 21:11:25 +0200, Simon Edwards wrote: > > > On Friday 08 September 2006 01:51, David Boddie wrote: > > > > Reading through the SIP files for PyKDE, you find lots of information > > > > about the way the KDE APIs have evolved over time. If the bindings > > > > were too closely tied to some schedule where development was frozen > > > > too early before a release, > > > > > > You mean "too late before release" I assume. > > > > Actually, I meant that if the bindings were frozen along with the rest of > > the branch then there may not be enough time to stabilize them, > > especially if the core developers are working on their APIs right up to > > the freeze. > > I see what you mean. Updates to the bindings in PyKDE won't be able beat > the general KDE feature freeze. The dependancies just don't work that way, > as you know. PyKDE will have to be an exception to the general rule, and > we'll just have to explain this to the KDE release team in advance. They'll > understand. :) I still think there is enough time between FF and release to > get things updated and tested. > > Things and features that *don't* depend on the APIs in kdelibs should still > obey FF though. > > > > Or at the very least make a freezing APIs *strongly* recommended. > > > > As long there are no last minute API changes. Sometimes you just can't > > recommend something strongly enough. :-/ > > Last minute API changes shouldn't happen too often. It should be possible > to monitor commits to kdelib header files.
Actually, it should be possible to generate PyKDE on the fly from the kdelibs h files. That's what sip does now - it generates C++ on the fly when you build PyQt or PyKDE. This would just move the process back one level. I would be hesitant to claim presip is as reliable as sip, but if you remove the need for versioning, it already works pretty well. Otherwise, someone can develop a new tool, or modify an existing one to do the same thing. The one thing you need to have is a lot of knowledge from the previous PyKDE version - handwritten code, methods to ignore, docs, etc. That info is all in the previous version's sip files, or could be encapsulated in metafiles in XML or whatever. presip can be modified to output XML too - I've just never bothered to do it and don't have a spec for it. So basically, you would create a base PyKDE version that's complete. At build time, you run a tool to generate new sip files from the latest kdelibs, and combine with the info stored in the previous version (but don't do versioning as such). After that, the build process is the same as it is now. The new sip files (after any manual fixes) become the new "base" version. While you always have a valid set of sip files (if you use those instead of some metafile solution) that could be built, you always generate a new set to the current kdelibs state each build. You might have to modify the tool or project files after the code freeze in some rare cases to satisfy last minute changes (if they require handwritten code, or use syntax the tool doesn't know how to handle), but I'd consider those to be "bug-fixes", and it seems to me the development process should be able to allow those. There are some potential problems, but not many and none too serious. Longer term, any PyKDE version could be built the same way, so the idea of distributing a tool and metafiles instead of sip files would seem like a reasonable solution, especially since, in theory, I'd never have to write a new version of PyKDE again :) And everybody would be up to date except for some handwritten code (and a lot of that could be built into a tool also - it was at one time, but I pulled it out). There are some non-trivial details to work out, but I think it's worth considering. Jim _______________________________________________ PyKDE mailing list [email protected] http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
