[prev in list] [next in list] [prev in thread] [next in thread] 

List:       pykde
Subject:    Re: [PyKDE] Error compiling PyKDE
From:       gerard.vermeulen () grenoble ! cnrs ! fr
Date:       2004-10-15 18:43:05
Message-ID: 20041015183321.M16244 () grenoble ! cnrs ! fr
[Download RAW message or body]

On Fri, 15 Oct 2004 11:27:44 -0700, Jim Bublitz wrote
> On Friday 15 October 2004 10:48, gerard.vermeulen@grenoble.cnrs.fr wrote:
> 
> > 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).
> 
> No problem - it always surprises me when distributors make changes. 
> I suspect it comes from trying to stay on top of the latest KDE 
> release, because most of the problems look like leftovers from 
> earlier (probably beta) releases rather than things that actually 
> need to be changed to make KDE functional.
> 
> > 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.
> 
> The fixes are usually pretty simple. Roberto Alsina pointed out that 
> at least some distros include an /etc/*release file (eg I have 
> /etc/SuSE-release on this system). I can use that to tailor a 
> version with configure.py if it's present on enough distributions.
> 
> To answer my own question about how to implement this: I think 
> enough people use PyKDE for "personal" applications that it makes 
> sense to make all usable features available. That would mean (in the 
> case in this thread), that setFileName would be available to 
> everyone except Mandrake users. People who write applications for 

Agreed, of course.  But if users can keep distributions from
making such changes, we would not spent hours on workarounds :-)
(distro's crank out new releases too fast)

> more general use would need to be aware that setFileName isn't 
> available on Mandrake, but that's no different than what a C++ 
> programmer would have to do in the current situation.
> 
> The philosophy behind PyKDE has always been to make as much of KDE 
> available as is reasonably possible and I'd like to continue that.
> 
> Once again, I'm not picking on Mandrake - similar things happen on 
> every distribution.
> 
No problem. I like Mandrake very much, because of the way they
interact with their community, but on some of my systems I run
SuSE, because SuSE's kernels are more stable.

Anyhow, this Mandrake has:
[packer@slow packer]$ cat /etc/mandrake-release
Mandrake Linux release 10.0 (Official) for i586
[packer@slow packer]$ cat /etc/redhat-release
Mandrake Linux release 10.0 (Official) for i586

All Mandrake's I know have also an /etc/redhat-release

Gerard

_______________________________________________
PyKDE mailing list    PyKDE@mats.imk.fraunhofer.de
http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
[prev in list] [next in list] [prev in thread] [next in thread]