Gangway, porting new modules
Today was a porting day for new KDE SVN modules to Solaris. We have 12 modules that compile cleanly (or relatively cleanly: there are still gobs of warnings that might be worth pursuing). So then we can choose one of two things: fix outstanding known bugs in the existing modules and go runtime testing and examine candidates for OS-specific features, or move on to other modules and see what happens. I chose the latter, knowing that Stefan was working on some of our showstoppers in kdebase. As an aside I took Stefan’s work on Capseo and turned that into a package, and finished compiling and uploading the basic KDE4 dependencies (through Qt 4.4.0) for SPARC.
So the first module I attacked was kdemultimedia. I think I might want to have juk or kscd on my system (this assumes that at some point my too-modern NVidia HDA chip becomes supported or I take the time to plug in one of my left over SB16s). Unfortunately, kdemultimedia uses libworkman, which is just some of the ugliest code I have seen in a long time. Part of the problem is most likely that the Solaris code there hasn’t been updated in a long time. Suddenly forcing it into SS12 and Nevada is not pleasant. The code layout doesn’t help much either; I recently read Beautiful Code and agree heartily with the piece on code formatting consistency: it’s not so much how you format as that it’s consistent within one piece of code. Anyway, after bumping my head on that for a bit I decided that code with fewer OS and hardware dependencies might be nice.
So I ported KOffice instead.
A wc(1) on the files I could find tells me it is 1.3M lines of source. That’s a lot of lines to go over, but the wonderful thing is that KOffice sits on top of several abstraction and convenience layers (KDElibs, Qt) that make the code pretty darn clean. And there’s no pesky hardware to deal with, either. So it’s not midnight on sunday yet and I’ve got a it-compiles stage of KOffice (downloading it from our cruncher to test it is going to take too long tonight).
The diff is 38k, of which I will be pushing most upstream as quickly as possible. Most of the issues that need patching are, in fact, little C++ corner cases that slip by in gcc and garner complaints in SS12. Here’s my top three list:<ul><li>The constructor for class A is called A()
, not A::A()
. No attempts at QPen::QPen()
, please. I can see how this is enticing syntax to slip into, for sure. It matches what you would expect of a static method like A::createA()
.</li><li>Math functions that are defined both for double and long double, like pow()
, don’t like integer arguments. pow(2,n)
is ambigious because the compiler can’t know where to cast that int 2 to. Add a .0 or a .0L depending on what you want. Or, heck, (double)2.0
if you’re like me and can handle some extra redundancy.</li><li>Numeric constants in math.h may or may not show up in C++ code. In any case, numeric_limits is a template class that proves much better C++-style access to things like NaN and infinity (yes! touch infinity with template specialization) than the #defines do. Use std::numeric_limits<double>::quiet_NaN()
for a NaN.</li></ul>And that’s about it. Reading through KOffice code has been generally pleasant. Although I often don’t understand what the purpose of the code is (Krita for instance) it looks elegant and well-thought out. And that makes it fun to work with; the clay from which interesting things are made.
The Wayback Machine ⏲ does not archive everything. Broken links are marked with a 💔.