Akregator is a KDE utility for retrieving and displaying syndicated web feeds in formats such as Atom and RSS. I am interested in dipping into some of Akregator's bleeding edge features; the Akregator development team is primarily managing these features within the /trunk directory of KDE's Subversion repository, where KDE 4 development is underway. Some of the KDE build documentation warns that “very few things work or compile at all” with the pre-KDE 4 code, and this warning may turn some developers away from trying to use this code at this early stage of the KDE 4 effort.

If you are like me in the general sense that you want to experiment with, or even hack on, the next generation of KDE or associated components, then you may be interested in this brief report, which summarizes my own efforts to build parts of the trunk. The trunk is buildable with a little help: some from you, and some from a thorough build management tool called kdesvn-build. In the remainder of this article I will provide a glimpse into this tool, share some of my experience on how to use it effectively, and describe what else needs to be done to get this raw body of code into a minimally usable state. I also provide a summary of the current "buildability" of the code; you can skip directly to that section if you're not interested in my experience with the build tools.

It is likely possible to download and build the source through a series of manual steps, but I had problems with that approach and so I turned to kdesvn-build, which managed those problems for me. Kdesvn-build is a Perl utility that manages retrieving and building KDE components, and tracks the results. It performs actions largely as you would perform them on the command line, but has a large degree of built-in awareness about the KDE project's layout and build needs. It has been around since April, 2005 (although it used to be kdecvs-build before that). It reached version 1.0 (which its author admits is somewhat arbitrary) on February 2, 2006.

As I hinted at earlier, KDE development is now managed in a Subversion repository, which means that you will need a Subversion client to pull down the latest code. One of the first problems I had, which first manifested during my attempt at a manual build but which would also affect using kdesvn-build, is that while I had a Subversion client, I needed one with SSL support because part of each main KDE package is stored behind an SSL connection. My Subversion client did not have SSL support built in, so I had to upgrade. To check your Subversion install, run:

$ svn --version
    

And you should see "handles 'https' scheme" in the output. It turns out that kdesvn-build will also help you by retrieving and properly storing the SSL certificate that the KDE repository uses.

The other problem I had with the manual approach, which ultimately drove me to use kdesvn-build, was KDE's recent switch to using unsermake as its recommended make tool. I didn't know how to properly set up the environment to use unsermake, but kdesvn-build will build and use it without any hassle. Unsermake also offers features, such as build progress indication, that kdesvn-build uses to provide a more intelligent build interface.

The point here is simple: use kdesvn-build for updating and building your KDE working copy. Its documentation is excellent, and will guide you through the process of installing, configuring, and using it. Still, there are some things that I found particularly useful. Want to skip the Subversion update, and just continue building from the component which last failed to build (useful for fixing compilation errors and then recompiling)? The --resume-from=component argument gives you that ability. Want to have the build stop when it encounters a failure (instead of moving on to the next module)? Use the --stop-on-failure=true argument to get this behavior. Finally, kdesvn-build will try to build a component a number of times before actually giving up, by default. If I know that a failure is "unrecoverable", such as a syntax error that I am trying to fix, I use the --no-rebuild-on-fail argument to disable this feature. There are a number of additional useful command line arguments to kdesvn-build, but they are fairly obvious and I leave it as an exercise to the reader to discover them.

The comments in the sample kdesvn-build configuration file suggest using a "buildable" snapshot of kdelibs instead of the version currently in the trunk; I have so far only tried to build the arts component, that snapshot of the kdelibs component, the kdebase component, and the kdepim component (which contains Akregator). Did these build? No. I had to make five small changes to get everything I needed to compile. The changes I did make are almost certainly not correct, although they did not affect the application in which I am interested. As a result, you can put more or less effort into "correctly" fixing the source based upon your goals and your focus within the KDE codebase. Even with the minimum number of changes necessary to compile these components, the build process includes a large number of compilation warnings, including a number of hardcoded developer warnings about things that are deprecated or that still need to be ported.

While the code didn't build for me out-of-the-box, after I was able to convince it to build it did actually run. I was able to bring up a usable KDE 4 development desktop, although it is still quite unstable. I have not done much testing beyond that. Once again, kdesvn-build provides useful documentation describing how to run KDE 4 once you've built it. The key pieces are ensuring that the QTDIR environment variable points to the build or installation location of QT 4, that the KDEDIR environment variable points to the installation location of your shiny new KDE build, and that your PATH environment variable includes $KDEDIR/bin. If you don't take other precautions, you may also want to set up a separate user account for running KDE, so that the new KDE doesn't do "interesting" things with your current KDE configuration.

Initially, I was interested in determining whether or not the newest Akregator code would display a hyperlink for Atom entries back to the original entry, if one is present. (The current stable Akregator does not, although it does for RSS entries.) Happily, the newly built Akregator actually runs, although it still has the old functionality—no hyperlink. And now I get to see if I can actually work my way through the code to try to contribute. The story continues.