It is possible to download an entire repository but have the build system leave out a few directories when it does the build. This requires that the module uses CMake and that the module's build system allows the directory to remove to be optional.

This is controlled with the do-not-compile option.

module kdebindings
  do-not-compile python
end module

Subversion supports managing the history of the KDE source code. KDE uses this support to create branches for development, and to tag the repository every so often with a new version release.

For example, the KMail developers may be working on a new feature in a different branch in order to avoid breaking the version being used by most developers. This branch has development ongoing inside it, even while the main branch (called /trunk) may have development going on inside of it.

A tag, on the other hand, is a snapshot of the source code repository at a position in time. This is used by the KDE administration team to mark off a version of code suitable for release and still allow the developers to work on the code.

In Subversion, there is no difference between branches, tags, or trunk within the code. It is only a convention used by the developers. This makes it difficult to properly support branches and tags within kdesrc-build. However, there are some things that can be done.

Support for branches and tags is handled by a set of options, which range from a generic request for a version, to a specific URL to download for advanced users.

The easiest method is to use the branch and tag options. You simply use the option along with the name of the desired branch or tag for a module, and kdesrc-build will try to determine the appropriate location within the KDE repository to download from. For most KDE modules this works very well.

module kdelibs
  branch 4.6
  # other options...
end module

module kdemultimedia
  tag 4.6.1
  # other options...
end module

kdesrc-build supports two options for situations where branch and tag guess the correct path improperly: module-base-path and override-url.

kdesrc-build normally will update, build and install all modules in the specified list of modules to build, even if a module fails to build. This is usually a convenience to allow you to update software packages even if a simple mistake is made in one of the source repositories during development that causes the build to break.

However you may wish for kdesrc-build to stop what it is doing once a module fails to build and install. This can help save you time that will be wasted trying to make progress when modules remaining in the build list will not be able to successfully build either, especially if you have not ever successfully built the modules in the list.

The primary method to do this is to use the --stop-on-failure command line option when you run kdesrc-build.

This option can also be set in the configuration file to make it the normal mode of operation.

It is also possible to tell kdesrc-build at runtime to stop building after completing the current module it is working on. This is as opposed to interrupting kdesrc-build using a command like Ctrl+C, which interrupts kdesrc-build immediately, losing the progress of the current module.

As mentioned above, it is possible to cause kdesrc-build to gracefully shutdown early once it has completed the module it is currently working on. To do this, you need to send the POSIX HUP signal to kdesrc-build

You can do this with a command such as pkill (on Linux® systems) as follows:

$ pkill -HUP kdesrc-build

If done successfully, you will see a message in the kdesrc-build output similar to:

[ build ] recv SIGHUP, will end after this module

Once kdesrc-build has acknowledged the signal, it will stop processing after the current module is built and installed. If kdesrc-build is still updating source code when the request is received, kdesrc-build will stop after the module source code update is complete. Once both the update and build processes have stopped early, kdesrc-build will print its partial results and exit.

kdesrc-build used to include features to automatically attempt to rebuild the module after a failure (as sometimes this re-attempt would work, due to bugs in the build system at that time). Thanks to switching to CMake the build system no longer suffers from these bugs, and so kdesrc-build will not try to build a module more than once. There are situations where kdesrc-build will automatically take action though:

If you make a change to a module's option settings, or the module's source code changes in a way kdesrc-build does not recognize, you may need to manually rebuild the module.

You can do this by simply running kdesrc-build --refresh-build module.

If you would like to have kdesrc-build automatically rebuild the module during the next normal build update instead, you can create a special file. Every module has a build directory. If you create a file called .refresh-me in the build directory for a module, kdesrc-build will rebuild the module next time the build process occurs, even if it would normally perform the faster incremental build.

% touch ~/kdesrc/build/kdelibs/.refresh-me
% kdesrc-build

You can tell kdesrc-build to start building from a different module than it normally would. This can be useful when a set of modules failed, or if you canceled a build run in the middle. You can control this using the --resume-from option and the --resume-after option.

% kdesrc-build --resume-from=kdebase

% kdesrc-build --resume-after=kdebase

If the last kdesrc-build build ended with a build failure, you can also use the --resume command line option, which resumes the last build starting at the module that failed. The source and metadata updates are skipped as well (but if you need these, it's generally better to use --resume-from instead).

Similar to the way you can resume the build from a module, you can instead choose to update and build everything normally, but ignore a set of modules.

You can do this using the --ignore-modules option. This option tells kdesrc-build to ignore all the modules on the command line when performing the update and build.

% kdesrc-build --ignore-modules extragear/multimedia kdereview

You can change the setting of options read from the configuration file directly from the command line. This change will override the configuration file setting, but is only temporary. It only takes effect as long as it is still present on the command line.

kdesrc-build allows you to change options named like option-name by passing an argument on the command line in the form --option-name=value. kdesrc-build will recognize whether it does not know what the option is, and search for the name in its list of option names. If it does not recognize the name, it will warn you, otherwise it will remember the value you set it to and override any setting from the configuration file.

% kdesrc-build --pretend --source-dir=/dev/null

It is also possible to change options only for a specific module. The syntax is similar: --module,option-name=value.

This change overrides any duplicate setting for the module found in the configuration file, and applies only while the option is passed on the command line.

% kdesrc-build --kdeedu,build-dir=temp-build