On Thursday 28 September 2006 10:48, Simon Edwards wrote:
> Funny you should mention that. We on the PyKDE list have been discussing
> that a bit in the last few weeks. The idea of developing PyKDE[1] in KDE's
> SVN and releasing up-to-date bindings synchonised with KDE, was positively
> received. Some details needs to be worked out, but it looks like it is
> going to happen.

I'm not sure if that discussion came to any conclusion. Do you have some 
process in mind, or do you want to adapt my process?

If the latter, I have presip pretty well cleaned up and the rest of the 
process committed to scripts (version #s in various files and doc, generating 
docs, computing svn adds, etc). I used KDE 3.5.3 to do the clean up and 
generated 3.5.4 almost perfectly without any manual work (with one bug - an 
error in a base sip file and one qualification - neither 3.5.3 or 3.5.4 
required any new handwritten code).

In theory, it should be possible to write a shell script or Makefile to 
regenerate PyKDE end-to-end any time kdelibs changes. The only hitch is 
handwritten code (that gets flagged) and scalar types used as references or 
pointers (eg int*, bool&). sip will generate code for the latter, but it may 
not be correct without an annotation (/In/, /Out/ or /In, Out/) as h files 
are ambiguous in that respect. presip used to flag those too, but doesn't at 
the moment, so that would need to be fixed.

The other glitches are when sip syntax changes occur, although if you freeze 
the sip version, that won't be a problem. Some other tools would probably be 
useful - something to generate a report of flagged code (handwritten or &/* 
stuff as in the previous paragraph), and a post-processor to strip all of the 
versioning info if you want that (as for a specific KDE release it isn't 
relevant).

Basically you need a clean set of base files (presip can do most of the work 
creating those too) for each module (or a new module). Once you have that, 
presip will pick up anything new - entire files, classes, methods, enums, 
whatever. Of course it will also pick up new files, etc that you may not want 
or sip might not handle (eg, an h file full of template classes), so some 
manual intervention is necessary, but normally it shouldn't take more than 
3-4 hours (including one compile on a slow machine) to generate a new version 
- maybe a little more for major release (eg 4.1 to 4.2).

I'm more or less neutral about the approach you take - if you have some other 
method you'd prefer, that's fine with me. Also, don't expect what I have to 
be pretty - it's a hack and still has a lot of cruft from previous 
incarnations, some of which is amazingly difficult to remove. But if you're 
interested, I'll put something together and make it available, and do 
maintenance on it as required. 

Jim