[PyKDE] Error compiling PyKDE

[gerard.vermeulen at grenoble.cnrs.fr]

On Fri, 15 Oct 2004 10:10:13 -0700, Jim Bublitz wrote
> 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.
>
Sorry, Jim. I was too fast with finger pointing. A look in the Mandrake
patches for KDE-3.2.3 confirms that Mandrake changed the API of their
header files.

It comes as a shock to me that a distribution can change the API that
much (it is a pain for developers and PyKDE must catch them all).

Mauro, you know what to do :-)
> 
> 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.
>
Maybe it is possible to make a tool which parses the g++ compiler errors
and suggest possible fixes, mails the fixes to you and/or some public
repository *and* the guilty Linux distributor :-).
Nowadays the compiler errors are so clear that I could suggest the fix by
looking at the sip file in question (without seeing the header file).
So, it looks possible to catch most of those unofficial API changes
automatically.

Gerard