[PyKDE] Error compiling PyKDE

[Jim Bublitz]

On Friday 15 October 2004 00:00, Gerard Vermeulen wrote:

> > >Comment out (put // in front of) void setFileName in the lines
> > >
> > >%If (  - KDE_3_3_0 )
> > >                         KCatalogue (const QString& = QString ::null );
> > >    void                 setFileName (const QString&);
> > >%End
> > >
> > >
> > >};  // class KCatalogue
> > >
> > >of the file
> > >
> > >sip/kdecore/kcatalogue.sip lines 23-60/60 (END)
> > >
> > >Wipe out features, run python configure.py, run make
> >
> > It's going :)
> >
> > Since I don't understand what's going on... can you please tell me if
> > this a PyKDE bug or a mandrake one? (if I post a bug to mandrake
> > cooker's list I will post both)

> > Thanks again,

> I think it is a PyKDE bug.  The sip file declares setFileName as public
> while it has been declared private in the KDE header files (the sip
> file should match the header file).

> Mandrake would never change such a standard header file.

Sorry, but the distribution guys, including Mandrake, do make occasional 
changes to standard header files, and those changes break PyKDE and sometimes 
PyQt.

In this particular case, setFileName is declared public in the h file I used 
to generate PyKDE. I get my h files from kde.org most often, or occasionally 
a kde.org mirror. That would indicate to me it's a change in Mandrake. I can 
point to similar problems in the past with RH or SuSE. 

It's also quite possible that the Mandrake h files don't agree with the 
compiled libs (ie - this method might be public in libkdecore on Mandrake). I 
don't know that that's the case, but that kind of thing happens too.

As far as a solution to this kind of problem, I don't know of any reliable way 
to detect the distribution being used (any suggestions welcome). The other 
alternative is to provide a "distribution" switch for building PyKDE, but the 
success of that depends on a) users actually using it and b) me being aware 
of problems like this ahead of time.

The other alternative is to provide a "least common denominator" PyKDE. In 
this case, that means anyone wanting to use KCatalogue would not have access 
to the setFileName method because of the error in the Mandrake h file. I 
don't know if that's a big deal or not.  I don't like it as a policy, but 
that would also be necessary to allow PyKDE-based apps to run on any 
platform.

I'd be interested in people's input about how to handle this kind of thing.

Jim