Calligra/Building/3
Note
For the (latest stable - 3.1.0) Qt4-based Calligra, look at Calligra/Building/2. For Krita 3 & later (split into separate project) see Krita. For building on Windows, click here, for Mac OS X click here.
You are encouraged to update these pages with any new information you come across.
Preparation
Warning
Warning
Note
Recommended Setup
You must begin with a C++ development toolkit including gcc, git, and cmake. These applications will be available in your distribution's package repositories.
Next you must prepare a directory structure to contain your build. These instructions will assume the following following recommended layout:
- $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 why this is here. The build configuration given here is compatible with build automation scripts found on that page.
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 additional useful scripts and functions.
Getting the Source Code
Here we will walk through obtaining the source code to build the Calligra configuration of your choosing.
Download instructions
We will configure Git for easier access to KDE. 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
Git will expand kde:calligra to git://anongit.kde.org/calligra automatically based on your configuration. If you are following the recommended directory layout you should now have a source folder $HOME/kde/src/calligra containing the source code. If you accidentally cloned the source to the wrong place, you can simply move it to the new location. Git is extremely flexible about the location of its files.
Choosing the right branch to build
Now that you have got the Calligra repository you will be able to switch to the branch of your choosing. 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.
The latest stable version of Calligra is being developed on the calligra/2.9 branch. Other than the master branch it is still based on Qt4. See the specific instructions at Calligra/Building/2 .
Build Requirements
This section provides information about hard (required) and optional software packages needed to build the Calligra software. Thankfully, obtaining the dependencies for Calligra in the major distributions is often fairly straightforward through the package managers. For example on Kubuntu, most of the work is done by running:
sudo apt-get build-dep calligra sudo apt-get install libboost-all-dev exiv2
The exact commands needed will vary from distribution to distribution. For more information on how to use your package manager to obtain the dependencies below, please consult the distribution specific instructions. At the end of this section, you should have most of the dependencies from the list below installed on your machine.
Note
List of required dependencies
The following are the general must-have dependencies for Calligra. If you are selecting packages by hand please be sure you install the development library versions, preferably with debug symbols.
For all applications:
- Qt 5.3.0 or newer
- KDE Frameworks version 5.7.0 or newer. Not every single component is needed, see below.
- boost
- lcms 2.4 or newer
For Calligra Sheets:
- libeigen 3.0
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
Some packages are not necessary to build but will provide a better experience if present. If your main intention is to use an upstream version of Calligra for personal use you should include these.
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.
Breeze widgets:
- If you do not use the Plasma 5 desktop, you can provide the widget style through your package manager or by building directly, by building and installing first the kde:kdecoration repository and then the kde:breeze repository.
- To set the style to breeze, add to the kdeglobals file (somewhere in your .config/ subdir, depending on the XDG settings):
[General] widgetStyle=breeze [Icons] Theme=Breeze
Missing Packages
Sometimes not everything goes as planned, and you won't have all the dependencies you needed. Such missing dependencies, both mandatory and optional ones, will be logged at the end of the CMake run. It should be clear to figure out if anything is missing. If this happens, you can simply browse through your package repository to install it. Please update this page with any issues you run into.
Although Calligra's CMake scripts specify that only Qt5 should be use, it is possible that CMake will slurp up Qt4 libraries erroneously. If this happens, you may need to specify the version of Qt you want to use through the external configuration tool "qtchooser." Make sure Qt5 will be used.
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
This step can be greatly customized through CMake's powerful interface; there are more details in the next section. ('Alternatively, the 'cmakekde tool can be used as well. This is explained on the build instructions for KDE)
Building Calligra is a CPU intensive procedure, and the more processor cores you utilize the better. Multicore builds are governed by the -j parameter in GNU Make. You usually want to start more processes than you have cores, though too many is sometimes inefficient. For a four-core machine, six processes should do the trick, so you'd want to use:
make -j6
Then type this command to install the software (though multiple cores are less important here):
make install -j6
Please follow the Running Calligra Applications instructions before trying to run an application.
CMake Build Options
CMake is a tool that automatically generates a list of configurations based on variables you feed it and the system configuration it detects. You may want to change the default options depending on your intentions.
The CMake Cache
When CMake finishes running, one of the files it produces in the build directory is called CMakeCache.txt - this file lists the values of every variable that was generated during the build process. If you notice a problem, it is a good place to look. There are several methods to edit these options.
- Re-run CMake in the current directory.
- This would look like
cmake . -DCMAKE_OPTION=NEW_VALUEThe command line directive -D specifies you are setting the value of the variable CMAKE_OPTION to NEW_VALUE. Note that all CMake variables are strings. - Enter the build directory and run cmake-gui.
- This runs a gui where you can edit files. On Ubuntu this program is found in package
cmake-qt-gui. - Edit CMakeCache.txt by hand.
- This is quite easy to do with a good text editor; CMake adds documentation strings that it finds listed with the variables.
- Use an IDE that supports CMake.
- This includes KDevelop and Qt Creator. Both provide a cmake-gui style configuration editor.
Faster re-builds with Ninja
The Ninja build tool can perform very fast build tree parsing. Although it is not possible to improve the initial build or the linking stage, Ninja is very useful when making small changes to the code and rebuilding, as the recompile is nearly instantaneous. Another benefit of Ninja is that its build instructions are contained in a single file, build.ninja, so it is very easy to examine any commands that have gone wrong. You can install Ninja from your package repos, although if you encounter problems the source version may be more up to date.
To request CMake generate Ninja build files instead of GNU Make build files, add the -G"Ninja" generator to your cmake command line:
cmake -G"Ninja" -[other options...] /path/to/code/
Although it is possible to reconfigure many cmake options using commands such as 'cmake . -DNEW_OPTION=1', it is not possible to switch between a Ninja and GNU Make build in the same build directory.
Ninja will automatically use all available CPU cores. To use it, simply replace make -j6 with
ninja
and replace make -j6 install with
ninja install
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.
Using Product Sets
By default, the build system tries to build all applications. Unless you are a great polymath or you find watching very long compiles relaxing it is unlikely that you want to build all of Calligra at once. Luckily Calligra defines a PRODUCTSET variable for CMake. You can either specify programs to use, or use predefined product sets.
For example, to build only Words and all modules needed for it, specify the WORDS product set by passing to CMake:
-DPRODUCTSET=WORDS
If you want to build several programs and their needed modules at once, you can use a list as follows:
-DPRODUCTSET="KEXI SHEETS"
Alternatively, you can use one of the predefined product sets:
-DPRODUCTSET=DESKTOP
More information about these options here.
Running Calligra Applications
After you have compiled and installed your desired application, 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 QML_IMPORT_PATH=$HOME/kde/inst5/lib64/qml:$HOME/kde/inst5/lib/qml:$HOME/kde/inst5/lib/x86_64-linux-gnu/qml 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
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
Common issues
In theory, this is all you need to have your new copy of Calligra up and running. It is very often the case that you your program will instead crash immediately with a strange error. Here is a collection of common errors ones you might encounter.
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 )
These symbol clashes mean you have multiple libraries with conflicting version information. It is very likely have a version of Calligra installed through your package manager, or you have not cleaned up a previous build of Calligra.
"XXX plugin is not installed. Program will quit now."
This error means you have not configured your plugins and environment variables correctly.
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.
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 -j6 make install -j6
Working with Multiple Versions
Note
Note
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'.
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:
# TOADAPT: LIB_SUFFIX as needed by your system
cmake-options -DCMAKE_BUILD_TYPE:STRING=debug -DBUILD_TESTING=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. Please consider submitting your first patches using Phabricator. Once you are comfortable putting together an acceptable patch, you can apply for a contributor account as explained on the KDE Techbase.
Distribution Specific Configuration Instructions
Debian-based Distributions
Debian, Ubuntu, Kubuntu and Mint should all follow the basic build instructions as described for Kubuntu. To install packages for other libraries may be needed. If you find you are missing any KDE Frameworks parts, these can be installed using 'apt-get build-dep kdelibs5.'
If you do not have the Plasma desktop environment installed, you must also install the Oxygen icon set:
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 : [2]
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
Note
List of Product Sets
Here you can find a list of the different Calligra product sets.
| Application | Product Set | |||||
|---|---|---|---|---|---|---|
| DESKTOP | OSX | ALL | Comment | |||
| Braindump | X | X | X | Not maintained, will (probably) be removed | ||
| Karbon | X | X | X | |||
| Sheets | X | X | X | |||
| Stage | X | X | X | |||
| Words | X | X | X | |||
| Gemini | X | X | X | Includes Words, Sheets and Stage | ||
| Other | ||||||
| Format Converter | X | X | X | |||
| Filemanager plugins | X | X | X | |||
| Okular plugins | X | X | X | |||
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.
Further Resources
- Useful hints for anyone who wants to hack on Calligra
- Developing With KDevelop The premiere IDE for KDE development and a great editor overall.
- Developing With QtCreator Recommended for more integrated Qt-specific documentation, and easier to install on Windows
- Pages about compiling KDE software for Windows
- Status of Calligra build on Windows (msvc 2008, mingw)
- Bulding Calligra on Windows