Calligra/Building/3

Note

These instructions are a work in progress. They are for the Qt5-based Calligra 3.x on Unix-like operating systems. For the (latest stable - 3.1.0) Qt4-based Calligra, look at Calligra/Building/2. For Windows, click here, for Mac OS X click here. Please feel free to update these pages with any new information you come across.

Preparation

Warning

Follow this guide as an ordinary user. Do not login as root or issue commands with sudo! Calligra should install and run correctly within in your home directory. If it doesn't, you have discovered a bug.

Warning

First, to avoid conflicting copies of configuration files, 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. If you have already installed Calligra, purge the settings files during your uninstall if possible.

Recommended Setup

You must start with a basic C++ development toolkit including gcc, git, and cmake. Obtain these from your distribution packages.

Here is the recommended directory structure to prepare for your build.

$HOME/kde/src/

source code

$HOME/kde/build/calligra

directory that Calligra will be built in

$HOME/kde/inst5

directory that Calligra will be installed in

The build directory for Calligra must be separate from the source directory. You can see more discussion of this here. The build configuration here is the one recommended in the scripts mentioned there.

Create these directories with:

mkdir -p $HOME/kde/build/calligra
mkdir -p $HOME/kde/inst5
mkdir -p $HOME/src

You may also want to check the Techbase instructions on setting up a build environment, which links to some useful scripts and functions.

Getting the Source Code

Here we will walk through obtaining the right source code to build the Calligra configuration of your choosing.

Downloading the Source

We will follow the recommended directory structure. The goal will be to put the source in the $HOME/kde/src/calligra directory, though this can be done in one of two ways.

• Option 1: download directly from git

We will set up the standard KDE Git configuration. Add the following text to your ~/.gitconfig:

[url "git://anongit.kde.org/"]
    insteadOf = kde:
[url "ssh://[email protected]/"]
    pushInsteadOf = kde:

This sets up a kde: prefix which allows us to use a shorthand for the KDE repository URL to use in Git. It sets up read access to happen anonymously, and directs pushes to authenticated SSH.

Now navigate to your build directory and pull the repository by executing:

 cd $HOME/kde/src/
 git clone kde:calligra

Notice how Git will expand kde:calligra to git://anongit.kde.org/calligra automatically based on your configuration.

• Option 2: download a repository tarball

Go to https://projects.kde.org/projects/calligra/repository. Press the "Tarball" button. Copy the url text and paste it on your command line. It will look like:

wget -c http://anongit.kde.org/calligra/calligra-latest.tar.gz

Unpack and cd into directory, then run

$ ./initrepo.sh

Choosing the version you will work with

Now that you have got the Calligra repository locally, either by option 1 or 2, you will be able to switch to the branch of your choosing. The latest development version of Calligra is 3.1.0 Alpha; currently developed in the branch frameworks. Calligra developers are currently porting Calligra to Qt5 and KF5 there. Once the porting is done, this branch will be merged to the master branch, to become the new current stable version 3.1. Currently, Krita is being developed on the Calligra/2.9 branch; until the port to KF5 is completed should visit the KDE 4 version of these instructions.

To check out the branch the porting is done, you can run

$ git checkout frameworks

From now on to update, you can run

$ git pull

or if you have local changes:

$ git pull --rebase origin frameworks

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 stable (master, calligra/x.y) and various feature branches.

Recommended way is to use git-new-workdir tool. This solution saves space (300MiB for a calligra branch instead of 1200MiB) and time. It 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:

To get the master into $HOME/kde/src/calligra:

$ git clone kde:calligra

Then, to get the Calligra 3.1.x into $HOME/kde/src/calligra-3.1:

$ git-new-workdir $HOME/kde/src/calligra $HOME/kde/src/calligra-3.1 calligra/3.1

The above means git-new-workdir <original clone's directory> <new source directory> <branch name>. As you see the <original clone's directory> is the master branch, and this is recommended convention.

Working with Qt Creator. Every source directory can be opened as a project in Qt Creator (by opening the central CMakeLists.txt, see Developing With QtCreator). Creator supports many projects opened concurrently. One of them is made active. Remember to set up variables for all Qt Creator projects (for each source directory) that you want to use in this IDE (see Developing With QtCreator again for instructions). Then you can switch between projects easily in Creator, build, run and debug projects.

Build directories. Please use separate build directory per branch, never share the same build directory for many branches if you don't want to encounter compile and configuration errors. A good naming scheme for building kde/src/{branchname} code is kde/build/{branchname}.

When many build directories are used, it's easy to switch between builds: just type make -j*** install in given build dir.

Removing directories. If you no longer need a build directory, you can safely remove it to safe space. You can also remove source directory that you created using git-new-workdir before. But the base source directory used by the git-new-workdir (or <original clone's directory> as mentioned before, typically containing master branch code, shall not be removed. Otherwise, 'workdir' branches (such as kde/src/calligra-x.y) will no longer work. This is because hard links to files in the <original clone's directory> are used while by each 'workdir'.

Build Requirements

This section provides information about hard (required) and optional software packages needed to build the Calligra software. Although Calligra's CMake scripts specify Qt5, Sometimes needed to specify which version of Qt you want to build with through external configuration tool like "qtchooser." Make sure Qt5 will be used.

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 5.3.0 or newer
• KDE Frameworks version 5.7.0 or newer. Not every single component is needed, see instructions below.
• boost
• 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:

For Kexi:

• KDb (master branch from the kde:kdb repository, packages may not exist yet, in turn KDb requires recommends icu, libicu and libicu-devel for unicode support as a dependency, and recommends SQLite and/or MySQL/PostgrerSQL client libraries). See Kexi/Porting_to_Qt&KF_5 for porting status.

For Kexi and Plan:

• KReport (master branch from the kde:kreport repository, packages may not exist yet). See Kexi/Porting_to_Qt&KF_5 for porting status.
• KProperty (master branch from the kde:kproperty repository, packages may not exist yet). See Kexi/Porting_to_Qt&KF_5 for porting status.

Optional Dependencies

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.

Optional Dependencies for Krita

For users who want to use Krita it is also recommended to install the Vc library. It is optional, but greatly improves painting speed. Use the stable version, currently 0.7.

Look & Feel

If you use the Plasma 5 desktop, you probably have the Breeze QWidget style and icon theme installed and ready for use. Otherwise you can build them as follows:

• Dependency of the Breeze style: build the kde:kdecoration repository in a standard way
• Breeze QWidget style and icon theme: build the kde:breeze repository using Qt5

To set the style to breeze, edit the kdeglobals (somewhere in your .config/ subdir, depending on the XDG settings);

[General]
widgetStyle=breeze

To set the icon theme, in the same file:

[Icons]
Theme=Breeze

Distribution Specific Instructions

Debian-based Distributions

On Debian, Ubuntu, Kubuntu and Mint, 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.

Currently this misses a few technically non-mandatory but important libraries:

sudo apt-get install libboost-all-dev exiv2

If you do not use the Plasma desktop environment:

sudo apt-get install kde-style-oxygen

On Linux Mint , you'll need to activate the software sources repositories manually. ( Search for 'Software Sources' in your menu then open it, On the tab 'Linux Mint Software' , check to activate 'Source code', On the tab 'Other Software' check to activate 'Ubuntu **.** <name> (source code) then close the windows to finish )

OpenSuSE

All the dependencies used for building Calligra can be installed by running:

zypper si -d calligra

( Note : enable in 'Yast' > 'Software Repository' the sources packages )

Fedora

All the dependencies used for building Calligra can be installed by running:

yum-builddep calligra
yum install gcc gcc-c++

Note : you'll need to compile the VC library on your own, version 0.7, follow recommendation of this comment : [1]

Arch Linux & Manjaro

All the dependencies used for building Calligra can be installed by running:

# pacman -Syu
# pacman -S base-devel
# pacman -S cmake automoc4 boost kdepimlibs eigen2 kdeedu-marble lcms2 libmariadbclient freetds xbase libwpg opencolorio libwps gsl glew fftw poppler-qt libkdcraw libodfgen openjpeg kdegraphics-okular pstoedit vc libvisio libetonyek libpqxx libspnav

Chakra

All the dependencies used for building Calligra can be installed by running:

sudo pacman -S kdelibs kdepimlibs eigen freetds kdegraphics-okular kdeedu-marble xbase libgsf libwpd libwpg libwps libvisio pstoedit glew gsl cmake automoc4 libspnav libqtgtl boost libkdcraw libpqxx fftw opengtl docbook-xsl create-resources lcms2 qrencode libdmtx

Mageia

(Mageia 5 alpha 1/Cauldron recommended for current git master version)
All the dependencies used for building Calligra can be installed by running as root:

urpmi task-c++-devel git li64boost-static-devel && urpmi --buildrequires http://mirror.internode.on.net/pub/mageia/distrib/cauldron/SRPMS/core/release/calligra-2.8.5-1.mga5.src.rpm 

Note

change the link to the src.rpm file to an actual up-to-date location.

Note

TODO: Dependency list tested for Krita+Karbon, only librevenge is missing required library. We probably need to add some more dependencies for other calligra applications.

Build Calligra

Reminder: it is not possible to build Calligra in the source directory. Set up your directories as described in the Recommended setup section above}}

If you are using the recommended directory structure:

cd $HOME/kde/build/calligra

A standard cmake configuration will build all products except Kexi. This is achieved by the command:

cmake -DCMAKE_INSTALL_PREFIX=$HOME/kde/inst5 $HOME/kde/src/calligra \
      -DCMAKE_BUILD_TYPE=RelWithDebInfo

(cmakekde tool can be used as explained on the build instructions for KDE)

Building Calligra is a processor intensive procedure, and the more processor cores you utilize the better. Multicore builds are governed by the -j parameter in GNU Make. For an eight-core build, the next command is to type:

make -j8

Then type this command to install the software (though multiple cores are less important here):

make install -j8

Please follow the Running Calligra Applications instructions before trying to run an application.

Faster builds with Ninja

The Ninja build tool can perform very fast build tree parsing. It is especially useful when making small changes and rebuilding, as the recompile is nearly instantaneous. You should check whether your package repo is up to date, you may want to consider installing Ninja from source.

To request CMake generate Ninja build files instead of GNU Make build files, add the -G"Ninja" generator to your cmake command line: cmake -D[etc. etc.] -G"Ninja"

Although it is possible to reconfigure many cmake options using commands like 'cmake . -DALTERED_OPTION', it is not possible to switch between a Ninja and GNU Make build in the same build directory.

Debugging options

Recommended for accurate debugging: The default build setting for CMake is RelWithDebInfo which is best for personal use if you want to use the latest upstream features. However this inhibits debugging using breakpoints, watchpoints, and using step by step commands in debuggers like gdb, as the code optimizer will some of the source code logic to speed it up. If you intend to develop Calligra, even if you will not use breakpoints you very likely want to turn on debug mode, as this also guarantees assertions, and makes sure all debug and warning messages are printed. To turn this on, set the Debug build mode by replacing -DCMAKE_BUILD_TYPE=RelWithDebInfo in the above with:

 -DCMAKE_BUILD_TYPE=debug 

Using Debug will result in a slower code but this can be acceptable in most cases during testing and development given the machine is fast enough.

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

-DCMAKE_BUILD_TYPE=KritaDevs

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 most interesting predefined product sets.

Application	Product Set
	DESKTOP	CREATIVE	ACTIVE	OSX	ALL
Active			X		X
Author	X			X	X
Braindump	X			X	X
Converter	X	X		X	X
Flow	X			X	X
Karbon	X	X		X	X
Kexi	X			X	X
Krita	X	X		X	X
Plan	X			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.

For those interested only in a single application, there are also product sets per application. These will only build all those internal products which are required or useful for the respective application.

The app-specific products sets are named by the app name:

ACTIVE, AUTHOR, BRAINDUMP, FLOW, GEMINI (since 2.9), KARBON, KEXI, KRITA, PLAN, SHEETS, STAGE, WORDS.

For example, to just build the KRITA product set, pass

-DPRODUCTSET=KRITA

on the CMake command line.

Fine-grained Selection

Advanced users and developers wishing to design completely own product sets can do so. An introduction into the product set system and how to define own sets can be found in the file CalligraProducts.cmake in the toplevel directory of the Calligra sources. This file also contains the complete list of internal products and their internal dependencies. Defining own product sets in a separate file, like described at the end there, is the recommended solution for this wish.

The easist approach is to combine multiple product sets together directly on the call to cmake, e.g.:

-DPRODUCTSET="KEXI SHEETS"

This combines and tries to build all internal required and useful dependencies of the apps Kexi and Sheets.

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

The BUILD_{something} variables are intended for backwards compatibility. For that reason, they are only supported for the braindump, flow, karbon, kexi, krita, plan, sheets, stage and words products, and may be dropped for another mechanism in the future.

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.

Type:

cd $HOME/kde/src/calligra
git pull --rebase
cd $HOME/kde/build/calligra
make
make install

(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.

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 custom prefix (which is recommended in this document), you have to set the environment variables as follows. These are example values reflecting the recommended directory structure:

export XDG_DATA_DIRS=$HOME/kde/inst5/share:$XDG_DATA_DIRS
export XDG_CONFIG_DIRS=$HOME/kde/inst5/etc/xdg:$XDG_CONFIG_DIRS
export PATH=$HOME/kde/inst5/bin:$PATH
export QT_PLUGIN_PATH=$HOME/kde/inst5/lib64/plugins:$HOME/kde/inst5/lib/plugins:$HOME/kde/inst5/lib/x86_64-linux-gnu/plugins:$QT_PLUGIN_PATH
export QML2_IMPORT_PATH=$HOME/kde/inst5/lib64/qml:$HOME/kde/inst5/lib/qml:$HOME/kde/inst5/lib/x86_64-linux-gnu/qml

export XDG_CONFIG_HOME=$HOME/kde/Settings
export KDETMP=/tmp/kdedev-$USER
export KDEVARTMP=/var/tmp/kdedev-$USER
export KDESYCOCA=$KDEVARTMP/ksycoca

Make sure temporary directories exist:

mkdir -p $KDETMP
mkdir -p $KDEVARTMP

Note

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

TODO: verify, fix 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/kde/inst5

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 BUILD_TESTING variable to "ON", either by issuing the command in the build directory:

cd $HOME/kde/build/calligra
cmake -DBUILD_TESTING=ON .

Or you can run ccmake . in the buld directory and set BUILD_TESTING 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.

Using kdesrc-build

If you use kdesrc-build, you might want to add these additional module definitions for KReport, KProperty and KDB, as wanted by Kexi & Plan:

module-set kreport
    repository kde-projects
    use-modules kproperty kreport
end module-set

module-set kdb
    repository kde-projects
    use-modules kdb
end module-set

Completely separate config file

You might also want a separate config file to build all of Calligra and the now external-Calligra libs like KReport etc. with kdesrc-build.

For that store this file in the toplevel dir of where the sources should be placed with the name "kdesrc-buildrc". Adapt anything tagged with "TOADAPT" where needed and save the file again. Then run "kdesrc-build" in that directory (UNTESTED, please try and improve):

global
  # TOADAPT: these dirs to what you like
  source-dir /home/user/kde/src/
  build-dir /home/user/kde/build/calligra
  kdedir /home/user/kde/inst5

  git-repository-base kde-projects kde:

  # KDE4_BUILD_TESTS kept for now, for old kde4_add_unit_test stuff to be enabled
  # TOADAPT: LIB_SUFFIX as needed by your system
  cmake-options -DCMAKE_BUILD_TYPE:STRING=debug -DKDE4_BUILD_TESTS=true  -DLIB_SUFFIX=64

  cxxflags -pipe -DQT_STRICT_ITERATORS -DQURL_NO_CAST_FROM_STRING -DQT_NO_HTTP -DQT_NO_FTP -Wformat -Werror=format-security -Werror=return-type -Wno-variadic-macros -Wlogical-op -Wmissing-include-dirs

  # TOADAPT: adapt number of jobs to what your system can do :)
  make-options -j1

  branch-group kf5-qt5
end global

module-set kdiagram
    repository kde-projects
    use-modules kdiagram
end module-set

module-set kreport
    repository kde-projects
    use-modules kproperty kreport
end module-set

module-set kdb
    repository kde-projects
    use-modules kdb
end module-set

module-set calligra
  repository kde-projects
  use-modules calligra
end module-set

Contributing to Calligra

Currently, development on KF5/Frameworks version of Calligra happens on the frameworks branch. Once all Calligra applications are finished porting, patches should be pushed to the master branch. The policy for which branch to push to is project specific. (TODO: ask for more detail.)

 Note that pushing your changes will only work if you have a KDE developer identity. This requires logging an SSH key You can get a contributor account as explained on the KDE Techbase.

Resources

• Useful hints for who wants to hack on Calligra
• Status of Calligra build on Windows (msvc 2008, mingw)

Possible Issues

If you get errors when running an application like:

krita(8565)/calligra (lib komain) KoPluginLoader::load: Loading plugin "Animation Tool" failed, 
"Cannot load library /home/michael/kde4/inst/lib/kde4/kpresentertoolanimation.so: 
(/home/michael/kde4/inst/lib/libkopageapp.so.7: undefined symbol:
_ZN28KoShapeContainerDefaultModel3addEP7KoShape)" ( 1 ) 

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.

See also

• Developing With QtCreator (recommended for convenient studying the code, coding and debugging)
• Bulding Calligra on Windows
• Developing With KDevelop
• Pages about compiling KDE software for Windows