Other Kdesvn-build features
Kdesvn-build has several options to control the amount of output the script generates. In any case, errors will always be output.
The --quiet option (short form is
-q) causes Kdesvn-build to be mostly silent. Only important
messages, warnings, or errors will be shown. When available, build progress
information is still shown.
The --really-quiet option (no short form)
causes Kdesvn-build to only display important warnings or errors while it is
running.
The --verbose option (short form is
-v) causes Kdesvn-build to be very detailed in its
output.
The --debug option is for debugging purposes
only, it causes Kdesvn-build to act as if --verbose was
turned on, causes commands to also output to the terminal, and will display
debugging information for many functions.
When being run from Konsole or a different terminal, Kdesvn-build will normally display with colorized test.
You can disable this by using the --no-color on the
command line, or by setting the colorful-output option in the configuration file to
false.
Disabling color output in the configuration file:
global colorful-output false end global
Kdesvn-build can send a e-mail report to an e-mail address of your choice when a module fails to build for whatever reason. The way it works is that you choose an e-mail address that Kdesvn-build will send from, and an e-mail address to notify when there is an error.
Kdesvn-build will then, at the end of a complete run, construct an e-mail if there were any modules that failed to build. The e-mail will contain an abbreviated failure log for each module. Only one e-mail is sent for a run, even if 15 modules failed to build.
This feature is not enabled by default. To enable it, you need to set
both the email-address and email-on-compile-error options. email-address
controls the address Kdesvn-build sends from, and email-on-compile-error
controls where to send the e-mail message to.
Kdesvn-build uses the Perl-standard Mail::Mailer module to send e-mail. It is included with Perl 5.8, and is installable with Perl 5.6. Mail::Mailer supports Sendmail (including Sendmail-compatible e-mail clients), native SMTP transport, and qmail.
Sending email from foo@example.com to bar@example.com on a build failure:
global email-address foo@example.com # From: address for any kdesvn-build e-mail email-on-compile-error bar@example.com # To: address for build failure e-mail end global
Are you short on disk space but still want to run a bleeding-edge KDE checkout? Kdesvn-build can help reduce your disk usage when building KDE from Subversion.
Be aware that building KDE does take a lot of space. There are several major space-using pieces when using Kdesvn-build:
The actual source checkout can take up a fair amount of space. The default modules take up about 1.6 gigabytes of on-disk space. You can reduce this amount by making sure that you are only building as many modules as you actually want. Kdesvn-build will not delete source code from disk even if you delete the entry from the configuration file, so make sure that you go and delete unused source checkouts from the source directory. Note that the source files are downloaded from the Internet, you should not delete them if you are actually using them, at least until you are done using Kdesvn-build.
Also, if you already have a Qt™ installed by your distribution (and the odds are good that you do), you probably do not need to install the qt-copy module. That will shave about 200 megabytes off of the on-disk source size.
One thing to note is that due to the way Subversion works: there are actually two files on disk for every file checked-out from the repository. Kdesvn-build does not have code at this point to try and minimize the source size when the source is not being used.
Kdesvn-build will create a separate build directory to build the source code in. Sometimes Kdesvn-build will have to copy a source directory to create a fake build directory. When this happens, space-saving symlinks are used, so this should not be a hassle on disk space. The build directory will typically be much larger than the source directory for a module. For example, the build directory for kdebase is about 455 megabytes, whereas kdebase's source is only around 195 megabytes.
Luckily, the build directory is not required after a module has successfully been built and installed. Kdesvn-build can automatically remove the build directory after installing a module, see the examples below for more information. Note that taking this step will make it impossible for Kdesvn-build to perform the time-saving incremental builds.
Finally, there is disk space required for the actual installation of KDE, which does not run from the build directory. This typically takes less space than the build directory. It is harder to get exact figures however.
How do you reduce the space requirements of KDE? One way is to use the proper compiler flags, to optimize for space reduction instead of for speed. Another way, which can have a large effect, is to remove debugging information from your KDE build.
You should be very sure you know what you are doing before deciding to remove debugging information. Running bleeding-edge software means you are running software which is potentially much more likely to crash than a stable release. If you are running software without debugging information, it can be very hard to create a good bug report to get your bug resolved, and you will likely have to re-enable debugging information for the affected application and rebuild to help a developer fix the crash. So, remove debugging information at your own risk!
Removing the build directory after installation of a module. The source directory is still kept, and debugging is enabled:
global configure-flags --enable-debug remove-after-install builddir # Remove build directory after install end global
Removing the build directory after installation, without debugging information, with size optimization.
global cxxflags -Os # Optimize for size configure-flags --disable-debug remove-after-install builddir # Remove build directory after install end global
Would you like to make a comment or contribute an update to this page?
Send feedback to the KDE Docs Team