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…
- 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 (
.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.
So I’ve released kdesrc-build 1.15 yesterday. There are lots of bugfixes and some minor features since 1.14.1. (I ended up skipping 1.14.2 despite some FIXED-IN: entries that claim otherwise).
You should read the release page if you want the full details (or just
git shortlog v1.14.1..v1.15 ;). A brief summary of the changes would be:
- kdesrc-build takes advantage of some elements of the
kde-build-metadata repository. Specifically:
dependency-data is utilized to re-order
kde-projects modules if necessary. This applies even to the order you give in your configuration file, but is probably most useful for modules that are automatically grouped until modules you’ve requested. For example, with the newly-converted
kdemultimedia module, this feature allows kdesrc-build to still know to build the libraries
libkcompactdisc before building
kscd (without you having to mention that order yourself).
It is important to note that this relies on the dependency data actually being accurate. If you’re a KDE developer who develops modules in the KDE Project infrastructure you can update the dependency data yourself, just checkout
kde-build-metadata and make your fixes. Just make sure that you only mark dependencies between modules in the KDE Project database at this point, there’s no way to depend on a generic git repository.
- Also supported is a listing of KDE Projects for kdesrc-build to ignore. This is mostly for things like websites which are tracked in
kde-projects but can’t be built. If you see that kdesrc-build is trying to be a KDE Project that can’t be built then please add it to
- Building and installing l10n packages (from SVN) works again. Sorry, non-en_US users for leaving that broken for so long.
- kdesrc-build doesn’t re-download the entire KDE Project database if it hasn’t changed.
- Modules on the command line with no matching entry in the configuration file is no longer automatically an error. Instead it is assumed to be a module from
kde-projects. An error is still raised if that ends up not being the case after looking up the database, but this allows for a quick-and-easy one-shot install of modules from
kde-projects (especially if the dependency data is correct… ;)
- In a similar vein (to allow for one-shot installs), the qmake build system is now (partially) supported.
qt-copy” is no longer special-cased. You can built Qt from any module name now.
- Aurélien Gâteau added support for Bazaar SCM (to allow building
Many of these features required some ongoing refactoring of the code so if I’ve broken something please let me know.
If kdesrc-build has been working for you at all you’ve probably been using it from its git repository so you probably wouldn’t notice much change. I’m mostly making the release for the benefit of distribution packagers and in order to mark off a mostly-stable spot before I start diving into the new roadmap I’ve posted to the source folder.
On that note, looking forward to the future there are some questions I want to put out, but that will be a separate blog post… enjoy the new release in the meantime!