[review] [PyKDE] gcc3.4 pykde kde 3.2.3
jbublitz at nwinternet.com
Tue Jun 29 22:03:00 BST 2004
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
> 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
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).
More information about the PyQt