Jump to content

Krita/linuxbuild: Difference between revisions

From KDE Community Wiki
Wolthera (talk | contribs)
remove opensuse deps.
Halla (talk | contribs)
Replaced content with "Please check the manual: https://docs.krita.org/en/untranslatable_pages.html"
Line 1: Line 1:
== Preparation ==
Please check the manual: https://docs.krita.org/en/untranslatable_pages.html
 
This guide explains how to build Krita from standard Qt 5 and KDE Frameworks 5 development packages provided with your favorite linux distribution.  This should be straightforward, but for more detail you can look into the old instructions for [https://community.kde.org/Calligra/Building/3 building Calligra.]
 
You'll need to install a whole host of fairly small packages. The easiest thing you can do is to run the cmake config, and read the output. CMake will tell you what dependancies are still missing, and also what each dependancy does. That way, if you for example do not care for audio playback, you don't have to install those packages.
 
<!-- This was put here because the list of dependancies is apparantly considered unmaintainable. -->
 
== Building Krita ==
Once you have installed the dependencies, you are ready to clone the Krita repository.
 
cd ~/kf5/src              (Or, wherever you want to download the source code)
git clone git://anongit.kde.org/krita
 
 
=== CMake commands ===
Krita's build system has diverged from the Calligra build system. For example, Krita does not use productsets any longer.
 
Optimization level <tt>RelWithDebInfo</tt> is nearly always good enough for everyday debugging, and it can be used to paint with. Basically we have two build modes: for painters and for developers.
 
<b>For painters:</b>
* disable unittests so  the build becomes faster
* disable safe asserts. it means when a not-too-serious problem arises, Krita will just dump a warning message into the console instead of crashing with an assert.
 
cd ~/kf5/build/krita
cmake ~/kf5/src/krita \                        ## your source directory
    -DCMAKE_INSTALL_PREFIX=~/kf5/inst \          ## your installation directory
    -DCMAKE_BUILD_TYPE=RelWithDebInfo \
    -DBUILD_TESTING=FALSE \
    -DHIDE_SAFE_ASSERTS=TRUE
make -j8 install
 
<b>For developers:</b>
* enable unittests so you never break the builds
* enable safe asserts. If a safe assert happens, it means there is a bug in Krita and should be fixed, even though recovery procedure can workaround it.
 
cd ~/kf5/build/krita
cmake ~/kf5/src/krita \                        ## your source directory
    -DCMAKE_INSTALL_PREFIX=~/kf5/inst \          ## your installation directory
    -DCMAKE_BUILD_TYPE=RelWithDebInfo \
    -DBUILD_TESTING=TRUE \
    -DHIDE_SAFE_ASSERTS=FALSE
make -j8 install
 
 
Remember that you can change build settings with <tt>cmake . -DNEW_SETTING</tt>  or by using <tt>cmake-gui</tt> found in the package <tt>cmake-qt-gui</tt>
 
== Environment variables ==
'''XDG_DATA_DIRS.''' You should need only one environment variable to run Krita 3:
export XDG_DATA_DIRS=~/kf5/inst/share:$XDG_DATA_DIRS
 
'''KRITA_PLUGIN_PATH.''' Krita's plugin loading can be a bit fragile, especially when debugging. You can force Krita to look in a specific folder for plugins using the environment variable <tt>KRITA_PLUGIN_PATH</tt>.  For example, on a Kubuntu system with an install for Krita in ~/, the plugins are located in ~/kf5/inst/lib/x86_64-linux-gnu, so for proper debugging:
export KRITA_PLUGIN_PATH="~/kf5/inst/lib/x86_64-linux-gnu"
 
'''QT_MESSAGE_FORMAT''' and '''QT_LOGGING_RULES'''
See <tt>main.cc</tt> and http://woboq.com/blog/nice-debug-output-with-qt.html
 
== Troubleshooting ==
# When '''building master and SIP''' you might want to add <tt>-DPYQT_SIP_DIR_OVERRIDE=/usr/share/sip/PyQt5/</tt> to make it find the files correctly. This is a bug in the current cmake files that will be fixed later.
# '''WARNING''' cmake versions 3.1.3 - 3.2.3 have some problems with automoc so the unittests in krita will not be built. If you happen to have this version of cmake (e.g. Ubuntu 15.10) please build hewer cmake manually and call the binary directly from the build directory

Revision as of 11:12, 15 January 2019