The future of kdesrc-build

As I hinted at in my recent post, it’s time for me to genuflect a bit on kdesrc-build “going forward”:

The idea for me, from the time I first submitted kdecvs-build to kdesdk way back in the day, was to make it as easy as possible to build the current/bleeding-edge editions of KDE, both to support KDE developers and to support testing from “power users”.

Over the years the software has adapted to the shift to SVN, the KDE 3->4 migration, the partial shift to Git, followed by the introduction of KDE Project infrastructure. Although I’m biased I believe it’s been useful in its intended purpose. So where do we go from here? I’ll just submit my current “road map” for comment and leave you all with a request…

The Roadmap

  • Add support for Qt 5. The changes to support not needing a module called “qt-copy” were the first step, now we must make the changes necessary to build the multiple Qt repositories that comprise Qt 5.
  • Continue the relentless (and sometimes painful) push to refactor the code. This has already achieved big positives in the new support for bzr and the qmake build system, but we need to go further to support other items, like:
  • An expanded test suite. Although I’ve had less “brown bag” releases than in 2003-2005, I still have commits that land in git that I have to have users note break things for them. There is a test suite, but much of the code is hard to test because it’s intertwined together (which will be improved by refactoring).
  • And finally, a lot of changes to continue to make it easier to run a bleeding-edge desktop:
    • Continue to improve the documentation.
    • Generate needed session-setup files for the user (.bashrc, .xsession, etc.). Don’t make the user have to copy a .bashrc somewhere.
    • A script to run the distro-specific commands necessary to install the prerequisites.

So my big question to you all is: Where are you going for documentation? What would you prefer? Currently the documentation quickly gets out-of-date. I’m quite willing to host it on UserBase instead if that’s easier, and the KDE documentation team is quite willing to support that as well. But I hardly have time to work on the program, let alone the documentation for it, so there would need to be some kind volunteers to occasionally go through and make sure the advice still makes sense.

Another question I have is: How recent a Perl do you all run? I have tried hard through the years to ensure that kdesrc-build dependencies are quite minimal (right now just Perl 5.10, libwww-perl, and XML::Parser). It would be nice to utilize some common but non-core Perl modules (which I don’t think is unfair, given that we’re talking about staying on the “bleeding-edge” anyways).

Finally, how tied are people to the “single-file kdesrc-build” concept? Right now kdesrc-build requires essentially no separate installation step because it’s just a single file. Would making the single file be a simple wrapper around “git clone-or-pull kde:kdesrc-build-modules ; $srcdir/kdesrc-build-modules/start $args” be too annoying?

The most important question is the documentation one though… the steps needed to build KDE change frequently enough that the docs should be really good, and I have not done a good job at that. :-( I’m open to suggestions.

3 thoughts on “The future of kdesrc-build

  1. afiestas Identicon afiestas

    I have been using kdesrc-build for years, back when I was a KDE user :p

    Something I have miss is be able to execute make install/fast in all projects, something like

    ./kdesrc-build -no-svn -no-build
    ./kdesrc-build -install-fast

    It is needed because from time to time we have to clean our bin directory and having to “make install” everything takes some time.

    Even more! a
    ./kdesrc-build reinstall would be phantastic xd

  2. mpyne Identicon mpyne Post author


    I think “kdesrc-build –install $modules” already does what you want for “reinstall” (and speaks to the doc issues ;).

    As far the other one you’re not the only one to request a way to run a different command to perform ‘make’ or ‘make install’ so I’ll probably open those up to user definition. (But then it still has to be documented well or the feature might as well not exist)

  3. Sam Danza Identicon Sam Danza

    You really need support for build configurations

    Example: Release, Debug, RelWithDebInfo

    each need different build directories, install directories, enviornment options, build flags and such (though just supporting -DCMAKE_BUILD_TYPE= is usually enough)

    I already accomplish the same thing with different rc files and the -rc-file option but it’s tedious, as I need to keep them in sync with each other on every change.
    A better solution is to say


    is default build dir, whereas each of the following override:

    and such. Supporting every variable like this seems like a good way to go.

Comments are closed.