March 2003 Archives

...is it insider trading if you're from the future?

If you didn't notice, I put KDE 3.1.1 in unstable now. It's looking pretty good, I got feedback from a user who figured out that compiler optimizations were the ones causing problems with kmail crashing on certain types of messages, so I've got that fix incorporated into both 3.1.1 and 3.1 in stable.

The thing that keeps amazing me whenever I use it is how fast KDE is now on OSX. It's really just as fast as it is under linux now.

Attached to this is what's going out as an announcement tomorrow. If you see anything that needs clarifying, let me know, otherwise, release the hounds!

Looks like I've got KDE 3.1.1 pretty much ready, going through one last build test with xfree86 4.3 to make sure everything's kosher. I'll hopefully be putting it in unstable tonight. Yay!

Dvorak: I'm smoking crack

    <zizban> its hopeless...dvorak's stupidity is incurable
<RangerRick> heh
    <lomion> ahh his x86 article?
    <lomion> he does those once every year or so
    <lomion> i guess hefigures eventually he will be right
  <michaelm> when his hit rating goes down
  <michaelm> then all the outraged/amazed/stupefied mac people come to read it
    <lomion> yeah
  <michaelm> and his hit rating goes back up again
    <zizban> yepper
    <zizban> I read those things and think "Not this again"
    <zizban> everyone knows JKH is secretly porting Darwin to the UltraSparc
    <lomion> sparklar

This is just an update on the work I've been doing for the last couple of days on KDE's build system. My previous post about am_edit was a bit premature, it turns out there are certain cases where there's just no way at getting at those things early enough without ending up reimplementing half of automake. It just makes more sense pre-processing the .am file.

So my next step was implementing my am_edit stuff as a wrapper for automake. It would basically take in an .am file, munge it into the new 3-way library/binary definition (libkdeinit_[foo].la, [foo].la, and [foo]), and then write that to .Makefile.am and generate .Makefile.in from that, and copy it to Makefile.in. It was ugly and hackish, and kind of worked, but really confused automake's targets that were created for rerunning automake when things changed.

So, that leaves me with the other option in "implement it in automake", and that is to implement it in automake. =)

However, since there is no chance at all that anyone building KDE is likely to run a custom hacked-up automake, I've followed coolo's suggestion and implemented it in unsermake, which is an automake-replacement written in python by coolo, for use with KDE.

I've just finished building kdelibs with it and it seems to be working just fine, other than some bugs which appear to be unsermake's problem, and not mine (I'm not certain yet.)

This will allow KDE to build out of the box on macosx if we can get things implemented properly. Stay tuned for more info.

For the love of God, don't languish in SourceForge-never-completed-land! This project is totally the answer to my code bounty.

I've managed to get the kdeinit autogeneration working with am_edit. I'm reworking the makefiles right now to make sure it's working out OK, but I've gotten through kdelibs now with my new Makefile.am format. Basically, all you need to do is define a program in the Makefile.am and set "KDEINIT = [progname]" and it will auto-generate a [progname].so module and a libkdeinit_[progname].dylib shared library.

Whoo!

I'm not sure what to think about this.

Looks like future Apple GCC releases will no longer have the cpp-precomp hack in them. Should save a lot of headaches in porting UNIX stuff.

Got KDE 3.1 moved to Fink stable this morning, so far things seem to be going OK.

Also been working on slicker stuff recently -- I cleaned up the build system some and made a RedHat RPM spec. You can basically build with a 'make rpm' now and get freshly baked packages. =)

I'm in the middle of importing the latest prerelease of KDE 3.1.1 into the KDE-Darwin tree. I also sent an updated version of the KDE-Darwin admin patch (including Sam Magnuson's changes) to kde-core-devel.

Lots of administrivia going on, but it looks like things are cleaning up nicely. Once I'm done with the 3.1.1 import, I'm going to take another look at making modifications to KDE's build system to build the module/binary kdeinit stuff automatically. Still haven't quite figured out how that's going to work.

Welp, I've updated the KDE ports in darwinports. I got it done last night but it took a while to test the builds. =D

I also made a slicker port that will build from CVS (assuming it's not broken at any given time).

I updated KDE to pogma's latest libtool patches, the build-time issue with genembed in keramik went away (yay!) and all appears to be well. I'm building kdelibs3-ssl 3.1.1 right now (against a prerelease tarball) and have found what I think are the last of the build bugs in 3.1.1.

He also added dyld support to libltdl, but I haven't integrated it with kde's personal version of it yet.

I'm totally hooked on this game Gang Wars. It reminds me a lot of the oldskool BBS games like TradeWars and such.

So it looks like WalMart is having some database problems on their entry about The Hobbit. That or I completely missed Maurice, the homosexual prostitute in my first reading of the book...

[ In case it goes away, I've archived it here. ]

So I just sent a big-ass e-mail to kde-core-devel about the libtool linking against -module thing, hopefully I get some kind of response back, if that can be solved, a huge amount of the KDE-Darwin patches can be undone.

Cross your fingers!

So it looks like Sam Magnuson from Trolltech got much of KDE building on Qt/Mac, we're working on getting our patches coordinated right now. Check out the screenshots:

Awesome!

I'll be speaking at PackMUG (the NC State Mac User Group) about Fink tomorrow at 5:30. Luckily my KDE build is working enough for me to have KOffice running again as of this morning, so I can make... err... view my presentation. [grin]

Wish me luck!

I've gotten the KDE build working again -- there were some minor buglets in changes I had made while cleaning up the patches. I found where it was getting messed, and fixed it now.

Also, I've integrated the arts esound driver into the KDE-Darwin tree, it appears to work just fine, I'm going to give it a good run and see if it has any lockup issues like the CoreAudio driver does. If it's alright, we're set for putting these updated 3.1 packages into unstable. If that looks good, I'll be able to put it in stable.

Yay!

There's an interesting discussion between Havoc Pennington (from RedHat) and Miguel de Icaza (from Ximian) on the issues of Gnome/KDE interoperability. Strangely, I find myself agreeing with both of them for the most part, although in the end I prefer KDE3 to Gnome 2 currently. One thing I don't understand is that one of Havoc's reasons for not liking KDE is the supposed duplication of code between Qt and KDE:

That said, we are on track to be *substantially* smaller and faster if we kill the duplication of platform in gtk vs. libbonoboui, speed up pixbuf handling, optimize fontconfig, and some stuff like that. kdelibs is *huge*, as is Qt, and they heavily duplicate each other.

It seems to me that this is an interesting point of view from someone who works on a framework that is entirely written in C. KDE makes very heavy use of subclassing, there is really not much duplication going on in the KDE codebase as far as I am aware (with some exceptions). If he were to point to issues of inefficiency in compilers' implementations of C++ where vtable lookups induced by subclassing was a performance issue, I would understand. It seems to me, however, that he's basically saying that KDE is doing specifically what it isn't, and what subclassing was designed for -- not having to duplicate code.

Just a bit of KDE news.

First, I've sent my admin directory patches back upstream to the KDE folks -- hopefully they'll be accepted soon.

Second, in doing a bunch of cleanup I've screwed up the KDE-Darwin tree so that it doesn't start right (kded and klauncher aren't working right). I'm working through it now, if all goes well, I'll have new KDE packages in unstable shortly with a bunch of minor bugfixes. Once I've confirmed those changes work (at least up through kdebase) I'll send those upstream to the KDE folks as well.

Third, the arts-locking-the-entire-system bug is STILL happening. If anyone has any CoreAudio debugging experience, please let me know. This is the major blocker for moving KDE 3.1 final into stable. It's tricky to track down, it doesn't happen when running under gdb or ktrace, it only happens by itself. :P

Fourth, word is that 3.1.1 gets tagged sometime this week for packagers, I'll let you know as things happen, hopefully I'll have the build issues worked out before then.