[PyKDE] PyKDE2 Announcement

[Jim Bublitz]

On 10-Jun-01 Bruce Sass wrote:
> On Sat, 9 Jun 2001, Jim Bublitz wrote:
>> On 09-Jun-01 Bruce Sass wrote:
>> > On Sat, 9 Jun 2001, Jim Bublitz wrote:

>> When you see how long it takes to compile (KDE2 is big), you won't even have
>> to
 
> Ya, I know, it took me 6 days to compile KDE2beta releases, really.

Not quite that bad :)

> A few weeks sounds much better than a couple of months, 'cause we have
> all seen how proposed release dates tend to slip. ;)

There is no release date, so it can't possibly slip :)
Seriously, I'm pushing this as hard as I can, because *I* want to use it.
 
> Is the manual hacking needed scriptable?

Right now I run SIP to create the C++ sources, and then just overwrite about 5
or 6  files in two different subdirectories with something pre-mangled that will
compile. So yeah, I could do that in a make file, but it sure is ugly. It'll be
fixed shortly, so it's not really a problem, except for me and for getting
things released.

> ...so there is really no way to know what is included in them, and
> which one(s) will be needed.  By including what you think are "extra"
> header files from KDE2 you are biasing the PyKDE2 source towards a
> specific distribution (the one you use) and a specific release of KDE2
> (the one the distribution used for the release of it you are using).
 
> I Think...

Well, this version will definitely be biased to a specific KDE release -
basically 2.1.1/2.1.2. Future releases might be multi-version, but there seems
little point at the moment. The KDE files needed are distribution neutral.

> ...more complicated "automake stuff" that provides a consistent build
> process across platforms is better than risking getting into a
> situation where building on <this> version of <that> system is a
> no-brainer, but ya gotta do <this that and the other thing> to build
> on a significant number of the other platforms PyKDE2 will run on.
> Not only is it doing the ones who get the no-brainer setup a
> dis-service (IMO)... wouldn't it make your job a little tougher if the
> simpler automake stuff resulted in bug reports from people trying
> out different customised "hoops" 'til the act comes together (so to
> speak).
 
> ...you should not worry about this, let the packagers for the various
> distributions sort it out via whatever dependencies mechanisms they
> have to work with.  In other words, forget about RPMs and DEBs, do a
> source tarball that depends on other source tarballs -- if some
> distribution's developer packages are broken with respect to the
> header files provided, it'll get fixed.

AFAIK, PyKDE has never been released *except* as a tarball requiring
./configure;make;make install, although it does build a spec file. I have PyQt
as an RPM on my distribution, but it was out of date by the time I
would have installed it.

The complications you're pointing out kind of makes my point though (or maybe
it doesn't). At any rate, I'd like to avoid a bunch of configure switches like
"--with-missing-SuSE-h-files=" and "--with-missing-RH-h-files=" or the
alternative being 4 or 5 lines of "-I" in the make file.

None of this is fatal, but it might be a big convenience issue for some people,
and really difficult for newbies. In the end, gcc will tell you what .h files
are missing and you can go get them. I'd rather avoid a lot of that - I hate it
when people ship stuff like that.

>> I've only had broadband for a little over a month, so I'm still sympathetic
>> with those people who have slow links - KDE source is fairly large for some
>> of
>> us, especially just to pick up a half dozen missing header files.

> How about making a separate tarball for this stuff, clearly marked
> with which version(s) of which package(s) for which distribution(s) it
> is needed with;

If I understand you correctly, this is how PyQt/PyKDE have always worked - they
haven't been tied to specific versions (PyQt2.x still works - mostly - with
Qt1.44). The sip files have versioning similar to #ifdef VERSION == type stuff
in C/C++ files. The versioning is picked up from ./configure and a qt file
(qglobal.h??), so it's relatively transparent to the user. That Phil has kept
this up by himself for this long is amazing in itself.

> All I know is that it worked from the start (PyKDE-1, once I installed
> the proper -dev packages ;), and I've had no problems since.  If I
> (with no C++ and only K&R C knowledge and at the time a relative
> newbie to Python) can rewrite the old PyQt(-1.xx) tutorials to jive
> with the new Qt-2.x tutorials, and end up with virtually identical
> results as Phil had 2-weeks earlier... someone is doing something
> right, and the prime suspect is Phil.

No doubt - which is why, although I think I could hack this stuff to work
sooner or later, I'm leaving the stuff I have any concerns about to Phil for
fixing. Most of the "quality" is built in to the process and SIP, but there is
a little bit of manually written code that I'm NOT doing (and that's why the
build is messed up). A man's got to know his limitations.

> I'm running a testing/unstable Debian system and have access to
> developer built packages for: Python 1.5.2, 2.0, and 2.1;
> post-KDE-2.1.1 (with 2.1.2 libs) and KDE2.2; Qt 2.3 and 3.0.
 
> I figure that if PyKDE2 was available now I would be able to build
> against any reasonable combination of the three, without too much
> trouble.

I hope you and a lot of other people do that - it'd be a great help.
Personally, I think KDE *needs* this (anybody see the /. question about
alternatives to VBasic today?), and I'd like it to be thoroughly wrung out as
soon as possible.

Jim