[review] [PyKDE] gcc3.4 pykde kde 3.2.3

[Jim Bublitz]

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