[PyKDE] Re: PyKDE

[Jim Bublitz]

On Friday August 8 2003 13:25, Andreas Pour wrote:
> Jim Bublitz wrote:
> > On Friday August 8 2003 00:54, Andreas Pour wrote:
> > > Jim Bublitz wrote:

>   import os
> + os.putenv("KDE_MALLOC", "0")
>   import libsip
>   import libqtc

> so it works no matter how the module gets loaded.

Cool - good solution!

> > kaccelbase.h is in the extra/ subdirectory and is taken from
> > the kdelibs source tarball for the appropriate version.
> > There are half a dozen or so .h files that are necessary but
> > not usually in kde3/include (and a few h files that need
> > some mods to work with sip or my code generator). Those h
> > files are all included with PyKDE under extra/ and build.py
> > points the make files to the correct versions (eg
> > extra/kde303/kaccelbase.h).

> As the API is considered private (and kaccelbase.h is marked
> private in its entirety, I believe) I am not sure why you
> expose the API.  The API is not supposed to be exposed :-). 
> There is no binary compatability guaranteed, and in this case,
> you can see how that leads to problems :-).

I haven't visited this particular issue in a year or more. The 
basic problem was that the *public* parts of the API are 
dependendent on some .h files that are not found anywhere in 
kde*/include - what's there is necessary but not sufficient. 
PyKDE always runs the list of files it binds against 
kde*/include and throws out any mismatches - the files in extra/ 
are required to satisfy dependencies in the public API (except 
for a couple which are modified - users' KDE h files are never 
modified by/for PyKDE)

The choice was between ignoring large parts of the KDE API in 
PyKDE, or adding a few extra .h files to the PyKDE distribution. 
Since the files come directly from the KDE source tarballs and 
are provided for each KDE released version specifically, they 
should be correct. That assumes what's in the source tarball .h 
files is the same as what's referenced in the kde*/include h 
files or libs, which is generally, but not universally true. The 
recent h file 'cleanup' that KDE did (I believe I read that 
somewhere) might have fixed the dependency problem, but I doubt 
it. That should help with sequence dependencies when building 
PyKDE though, which were also a pain.

In fact though, the problem wasn't in kaccelaction.sip, but most 
liekly in kaction.sip, which is part of the public API (and it 
was my mistake, not KDE's) - it likely got picked up in 
KAccelaction via inheritance or something similar (sip will pull 
in methods from parent classes when they're not explicitly 
defined in the subclass, which it should do).

> Maybe you have lazy symbol resolution turned on?  I don't.

I'm not sure - I just build against 'stock' distributions (except 
for KDE version upgrades).

Jim