KDE 4 (was: [PyKDE] PyQt 4 on openSUSE)

[Jim Bublitz]

On Saturday 09 September 2006 05:50, Sebastian Kügler wrote:
> On Friday 08 September 2006 21:44, Jim Bublitz wrote:
> > The other problem is having an environment to compile and test the code -
> > that turns out to be a big time consumer for me, especially if I'd have
> > to compile KDE. Which is why I wait for rpms before upgrading PyKDE. On
> > the other hand, PyKDE4 won't require all of the back-testing PyKDE 3 does
> > now, which is the other big time cost.

> We might be able to automate that on a KDE quality checking platform. In
> fact, I'm willing to take a look at that, if you can lend me a helping hand
> where needed.

> Could you give me more information about the requirements?

PyKDE (and PyQt) contain conditional blocks like:

%If (KDE_3_0_5 - KDE_3_2_3)
...
%End

which sip interprets to mean "only generate code for this block if
KDE 3.0.5 <= KDE target version < KDE 3.2.3", similar to the way a C 
pre-processor would handle #if.

I don't know how clear this'll be. Basically, assume you're generating version 
N[i] of PyKDE for a corresponding version i of KDE. That version should 
produce a valid PyKDE versions N[0] ... N[i] . Assume version P[i-1] of PyKDE 
(the previous release) already produces a valid PyKDE for P[0] ... P[i-1]. 
Then to back-validate N[i], all that should be necessary is to verify that 
for any versions j = {0 ...i-1}, N[j] produces the same sip file 
(semantically)  as P[j]. 

However, files for N and P for any value of j will not necessarily be in the 
same line-by-line order, therefore you have to A) parse N and P into 
something like a symbol table form to do the actual comparison or B) 
"pre-process" (for each version j) N and P and then verify that the 
semantically same  sip file is created for both versions, but not necessarily 
in the same line order (otherwise something like diff would work).

A) When you generate N using presip, you already have P in symbolic form that 
contains version information, plus a version H in symbolic form from the KDE 
*.h files and those are combined to form version N, which doesn't exist in 
symbolic form - it's output as a sip file. It would be necessary to modify 
presip to either a) produce a symbolic form of N during code generation or b) 
be able to parse N and P, and then compare N and P for compatibility in a 
separate run.

B) Without parsing, simply compute the lines that will exist in each file for 
N[j] or P[j] and then match lines. However, for strict conformity, you also
have to verify some other things, mostly access level (public, protected, 
private), but very strictly also class, namespace, and similar things, 
although the latter are very unlikely errors. Method A  already has that 
information too.

There are a few problems, like new sip annotations that might arise between 
versions, or moving a %MappedType to a different file, but those probably 
aren't a big problem.

The need for something like that arises mostly because there are a small 
number of cases where a) presip versions incorrectly,  b) fails to recognize 
that two methods or enums are equivalent across versions, c) fails to 
fully-qualify some identifiers (eg KIO::something::something_else), d) fails 
to recognize some stuff roughly equivalent to typedef substitutions and 
generates extra, sometimes incorrect code, e) gets access specifiers wrong or 
deletes code (mostly "private") that sip needs to see, f) re-inserts code 
that should be left out.

Generally, all of that happens correctly, but in a few cases it doesn't. The 
solution of course is to fix presip, which in most of the cases noted, is not 
especially easy. And writing something to validate presip is another level of 
code to debug and maintain, although for Method A, nearly all of the code 
already exists in presip - it's mostly a matter of putting together a front 
end to feed in the two versions and a back end to compare them. Basically, it 
would make presip easier to debug too.

It's also a better (or at least different)  test than compiling, because gcc 
can't detect omitted code and some similar problems, and the amount of unit 
testing to accomplish that would be huge (I've forgotten the stats, but there 
are something like 600 classes and maybe 10,000 methods and enums, plus 
versions).

Aren't you glad you asked?

Jim