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

[Jim Bublitz]

On Saturday 09 September 2006 05:04, Simon Edwards wrote:
> On Friday 08 September 2006 22:34, Jim Bublitz wrote:
> > On Friday 08 September 2006 12:11, Simon Edwards wrote:
> > > [development & testing time]
> >
> > Right - mostly because the compiles take so long, and there are at least
> > 5 releases (3.0.x - 3.5.x) to test against. But see below (I used to go
> > down to
> > the '.x' level at one time).

> Having PyKDE as part of the standard KDE release would mean that you only
> have to test against _that_ version of KDE and no other. kdelibs + PyKDE is
> simply one thing with one version number that works together. It wouldn't
> make sense to take the PyKDE bindings from one KDE release and try to use
> that with another version of KDE.

That's an excellent point I hadn't really considered (kind of a duh! moment 
for me - should have been more obvious). In that case, the process is much 
simpler:

Once you have a base version of PyKDE, the next version can simply create a 
new version from the next KDE, and pull in the handwritten code from the 
previous version. Then you manually add any new handwritten code that's 
needed (which usually isn't much), and you're done.

presip does that (generating a base version) with fewer errors than generating 
a combined version PyKDE, and the code to pull in the handwritten stuff 
already exists, as does the code to flag where new handwritten code is 
needed.

That should also simplify creating configure.py or whatever build machinery is 
required.

Looks like I should work on that first, especially since it should be pretty 
easy to do. That should also be able to stay more current during the 
development/release process.

> > > For KDE4 I want to see all of the extra dev support stuff that in
> > > "PyKDE Extensions" [1] rolled into PyKDE, along with support in CMake
> > > for building
> > > Python modules, sip stuff and being able to mix that with regular C++
> > > based
> > > KDE development.
> >
> > I, personally, won't go back to any of the Gnu "autotools" stuff, and I
> > absolutely refuse to do anything that involves m4. Even if I had the time
> > (and it takes almost more time than anything else), it's too ugly.  But
> > that can be automated too - just not by me. Other than that, I'm a pretty
> > nice guy. To be complete, I'm not a big distutils fan either.
>
> In my comment above I was thinking more of 3rd developers who are using
> PyKDE and need some kind of build system for handling installation, i18n
> messages etc. I wasn't thinking about the build system for PyKDE itself.
>
> As for autohell, it's history. All of KDE (kdelibs, kdebase etc) has or
> will move to CMake. A lot of KDE C++ applications can even be satisified
> with Qt4's qmake. I can't say what makes the most sense for PyKDE, except
> that it won't be automake. ;-)

> The advantage of trying to make use of CMake is that you can then leverage
> a lot of the tricky cross platform support and fixes in CMake wrt things
> like handling the C++ compilier and libraries, installation paths etc etc.
> And it provides a more consistent build method to packagers.

That's good news - I haven't kept up with that, and I'm not familiar with 
CMake, but will take a look.

Jim