Preparation

Warning

First, to avoid conflicting copies of software, make sure you do not have other copy of Calligra or KOffice either installed through the package manager of your distribution or installed in any other way. Calligra and KOffice are mutually exclusive!

Warning

Follow this guide as an ordinary user. Do not login as root!

Warning

Some distributions (*Buntu, Arch) are now making Qt5 the defaulft! That does not work. Do not try to use Qt5, use Qt4.

Recommended Setup

Here is recommendation of a directory structure:

$HOME/kde4/src/

source code

$HOME/kde4/build/calligra

directory that Calligra will be built in

$HOME/kde4/inst

directory that Calligra will be installed in

The build directory is needed because you cannot (or should not) build Calligra inside the source directory; the source and build directory have to be separated.

Create these directories with:

mkdir -p ~/kde4/src; mkdir -p ~/kde4/build; mkdir -p ~/kde4/inst

Advantages of this setup:

It is possible to have different builds (e.g. with different options out of the same source code)

David Faure's scripts can be used to make development easier. With those scripts "make" can be typed in the source directory and building will happen in the right (build) directory automatically.

Then calligra-3.1.0 will appear. You do not need to execute initrepo.sh in it, the code is ready to build. Please note there is a price for smaller download: to update the source code to a newer version, another .tar.xz should be downloaded. See the option 2 to see how to address this with one-time bigger updatable download.

Option 2: Alternative download from the git repository, what weights about 650MB. If you prefer, stable versions are also available on the git repository too. It is heavier but one-time download, the advantage is that lightweight updates can be obtained without a need for downloading entire source code again.

To get stable version x.y (currently 3.1.0) from git, first follow instructions for downloading the development version below, either the Option #1 (directly from git) or the Option #2 (download a repository tarball). Then you need to switch from the development version to stable version of the source code. To do so, in the main Calligra source code directory that has been downloaded, type:

git checkout calligra/3.1

calligra/x.y is a notation for branches in the Calligra project. For the latest stable version 3.1.0 the branch is called calligra/3.1 and contains code updates for current minor stable release 3.1.0 plus updates for the next minor planned stable update (if there is any planned).

Development Version

The latest development version of Calligra is 3.1.0 Alpha; developers always refer to it as to master. Applications from Master should always compile and be reasonably stable. Calligra developers never place experimental features there. Once tested and released, Master becomes the new current stable version 3.1.

TODO: Here we should explain local branches, staging and always-release-ready Master, if we have that setup.

Option 1: directly from git

To retrieve the source code from Git you have to use the following setup:

Option 3: if beta or rc version was released, the source code for the latest beta can be found on KDE's ftp calligra-latest. Uncompress the code so that $HOME/kde4/src/calligra is created.

Working with Multiple Versions

You will often want to have more than one build environment in parallel, for example if you want to work on both stable and unstable branches at the same time or several feature branches.

Recommended way is to use git-new-workdir tool. The solution is based on a single git repository clone multiplied to many separate source directories for each branch you wish to use, all without performing full clone (what consumes disk space and requires fetching each clone separately). It is explained in the Techbase article Multiple Work Branches and you can find the script there.

Example commands to have code for both Calligra 3.1.x and master versions:

Build Requirements

Required Dependencies

Note

A note for developers: to add (or remove) a hard dependency, an explanation of the reason, and possibly a discussion must be posted in advance on [email protected] The new dependency need to be packaged in the most widely used distributions (Debian, Fedora Core, OpenSuSE, (K)ubuntu). First try to make your new feature optional.

Following are the general must-have dependencies for Calligra (unless you really need to do otherwise, just install relevant binary packages):

Qt 4.7.0 or newer

kdelibs and kdelibs development files

the minimal requirement is currently 4.3.0, that or any later release packaged in your distribution is OK

On opensuse the development package is called libkde4-devel; on Ubuntu and Debian it is called kdelibs5-dev. (TODO: add info for other distributions)

Calligra should also build fine with either kdelibs from git repository (see techbase for an explanation on how to compile kdelibs from svn), needed for parts of Calligra build with the Mobile Frameworks Profile of the KDE platform (Calligra Words, Calligra Sheets, Calligra Stage, krita)

kdebase/runtime 4.3 or newer

cmake 2.6.2 or newer

lcms 2.4 or newer

libpng development package (libpng14-devel on opensuse, libpng-dev on Ubuntu/Debian)

development packages for other libraries may be needed; on ubuntu/Debian these can be installed using 'apt-get build-dep kdelibs5'

For Calligra Sheets:

libeigen 3.0

For Krita:

libeigen 3.0

libexiv2 >= 0.16

For Stage:

boost

For Kexi:

sqlite3 and sqlite3-devel packages (package names can differ on various distributions), version >= 3.7.10

icu, libicu and libicu-devel (unicode support)

Optional Dependencies

All optional dependencies are logged at the end of the cmake run, so it is easy to figure out what is missing. The buildsystem also reports what component will not be built because given missing dependency.

For users who want to use Krita it is also recommended to install the Vc library. It is optional, but makes the performance much higher.

Distribution Specific Instructions

Debian-based Distributions

On Debian, Ubuntu and Kubuntu, all the dependencies used for the packages can be installed by running :

sudo apt-get build-dep calligra

Note you'll need to activate 'software sources' in your repositories.

Additionnal more or less mandatory librairies for Ubuntu and derivatives :

Speed up

Recommended: Taking advantage of multi-core processors. On dual-core machines compilation can be greatly speed up with the -j parameter of the make program. For example whenever you are invoking make, for dual-core processor try to invoke:

make -j3

Similarly, for quad-core processor:

make -j5

Generaly for N-core processor use the -jN+1 parameter.

Recommended: Faster linking on Linux.Linking can take noticeable time in large software such as Calligra. On Linux Gold linker can be used to speed up this task. If you're building for Linux, install the Gold linker package and add the following to your cmake command:

(you can set the CMAKE_C_FLAGS adn CMAKE_CXX_FLAGS variables in your {build dir}/CMakeCache.txt file either using text editor or the ccmake tool)

Debugging options

Recommended for accurate debugging: The default debug setting is RelWithDebInfo which is suitable only for obtaining backtraces. If you are developing or debugging an application by setting breakpoints, watchpoints, using step by step command accurately in your debugger, if you rely on assertions, debug and warning messages, you can replace -DCMAKE_BUILD_TYPE=RelWithDebInfo with:

-DCMAKE_BUILD_TYPE=DebugFull

Using DebugFull results in a slower code. That can be acceptable in most cases during testing and development given the machine is fast enough. It is not intended for production releases of the software unless you know what you're doing.

Special case for Krita: If you are working on Krita, always use the KritaDevs option by setting:

-DCMAKE_BUILD_TYPE=KritaDevs

Updating and Rebuilding

If the source code has been cloned using Git, it is possible to update the source code with newly added changes and build again. Usually only changing parts will be built, so this operation would be faster than building the source code from scratch.

(note that you can always append the -jN option to the make command to speed up the build as explained earlier in the Speed up section.

Building Selected Applications

Using Product Sets

By default, the build system tries to build all applications. The recommended way to change this is to specify a different product set by setting the PRODUCTSET CMake variable. The following table illustrates the predefined product sets.

Application

Product Set

DESKTOP

CREATIVE

ACTIVE

OSX

ALL

Active

X

X

Author

X

X

X

Braindump

X

X

X

Flow

X

X

X

Karbon

X

X

X

X

Kexi

X

X

Krita

X

X

X

X

Plan

X

X

Sheets

X

X

X

Stage

X

X

X

Words

X

X

X

For example, to build the CREATIVE product set, pass

-DPRODUCTSET=CREATIVE

on the CMake command line.

Note

The set of included plugins, import/export filters and extra tools may differ between product sets. Consult the product set definitions in the cmake/productsets directory of the Calligra sources for detailed information about what is included in each product set.

Specific Product Sets

For convenience, specific cases have been covered by extra product sets.

Application

Product Set

KEXI

KEXI+SHEETS

KRITA

Active

Author

Braindump

Flow

Karbon

Kexi

X

X

Krita

X

Plan

Sheets

X

Stage

Words

Fine-grained Selection

Advanced users and developers wishing to design completely own productsets can do so. How to do that is described in the file README in the cmake/productsets directory of the Calligra sources. Creating own productsets is the recommended solution for this wish.

Alternatively, though not recommended, instead of designing completely own productsets, it is also possible to disabe products from a selected pre-defined productset. One does so by setting the corresponding BUILD_{application} variable to OFF. For example, to disable compilation of Krita and Karbon, you can pass

-DBUILD_krita=OFF -DBUILD_karbon=OFF

on the CMake command line. You can also do this using the ccmake tool included with CMake, which you may run after the initial CMake run but before you run make.

Note

Many components should not be disabled using BUILD_{something}. Set these variables with caution!

Running Calligra Applications

After you installed them, there are two options to now make the Calligra applications available for running.

Running from Command Line

If you have installed Calligra in a different prefix than KDElibs (which is recommended in this document), you have to set the environment variables as folows. These are example values reflecting the the recommended directory structure:

It is important to set KDEHOME to a directory different of $HOME/.kde, and if the directory does not exist, it will be created automatically.

Then in this special environment you need to register all the Calligra internal plugins, by executing:

kbuildsycoca4

Running from Menus or Desktop Icons

Instead of using KDEDIRS, you can add these lines to $HOME/.kde/share/config/kdeglobals file using text editor:

[Directories]
prefixes=/path/to/install

And then you need to register all the Calligra internal plugins to the system, by executing:

kbuildsycoca4

The advantage of this is that KDE will always look for the services where Calligra is installed.
For example for the recommended directory structure:

[Directories]
prefixes=$HOME/kde4/inst

Executing Unit Tests

1. To be able to execute unit tests, you need to explicitly enable them in the build configuration. To do so, set the KDE4_BUILD_TESTS variable to "ON", either by issuing the command in the build directory:

cd $HOME/kde4/build/calligra
cmake -DKDE4_BUILD_TESTS=ON .

Or you can run ccmake . in the buld directory and set KDE4_BUILD_TESTS to "on".

2. Then run the test by executing:

make test

or run a test app individually in the tests directories.

3. Note: It is recommended to execute

make install

before running tests.

CMake Build Options

When you enter your build directory, you can type "ccmake ." to see many build options, e.g. you can turn off compilation of apps you don't want - you can save time when compiling.

Here is list for Krita related options:

HAVE_MEMORY_LEAK_TRACKER [On/Off] - You can turn on compilation of the tool in krita which detects memory leak. If you want to help debug Krita memory usage, it is useful. Otherwise you just slow down your Krita.

HAVE_BACKTRACE_SUPPORT [On/Off] - It is related to the memory leak tool. If you activate, you will be able to see code path which leads to memory leak.

or crashes when starting an application, then you very likely have a version of Calligra installed through your package manager. As emphasized earlier in this document, you can only have one version of Calligra, and you should uninstall your packaged Calligra.