KDE PIM/Development/Start: Difference between revisions

From KDE Community Wiki
No edit summary
m (debugfull)
Line 79: Line 79:
     make-options -j4
     make-options -j4


     # Build with debugging information
     # Build with full debugging information
     cmake-options -DCMAKE_BUILD_TYPE=RelWithDebInfo
     cmake-options -DCMAKE_BUILD_TYPE=debugfull


end global
end global

Revision as of 16:21, 15 May 2017

Getting Started

To get started, all you really need is a git clone. After that, you can compile and run the latest-and-greatest (and maybe buggy) versions of the KDE PIM applications. When you find a bug, you can fix it, create a patch, and send it to us! That's the way KDE PIM applications are continually improving. There is much more information available to begin with, though.

Here is a checklist of things to launch yourself into the world of KDE PIM development. For lots of them, it is most important that you know they exist:

  • Subscribe to the right mailing lists. Read them regularly.
  • Browse the information about the development tools, to choose one. Most KDE PIM hackers use kate, vi, or emacs as editor and just compile in a konsole window, though.
  • Take a brief look at the Qt documentation. It is excellent, and you should know about QWidgets and QObjects a little before continuing.
  • Take a brief look at the KDE documentation. It is a bit overwhelming.
  • Spend some time over at the KDE Community website.
  • Get the prerequisites for building KDE PIM master. Note that you really want to follow master to make a positive contribution to KDE PIM.

If you work on or with the last released version, you're usually a month or four behind the times, and that makes a huge difference in KDE PIM. You can work with a stable system -- the latest released KDE libs and base -- and put (relatively) unstable PIM HEAD on it.

  • Clone the relevant Git repositories.
  • Compile it and install.
  • Report bugs, wishes, fix bugs, get involved!

Mailing Lists

Mailing lists are probably the ultimate source of development information. Follow discussions of KDE core and application developers and ask your questions. Unless you don't think about what you are saying, you will surely get an answer. Subscribe to the kde-pim mailing list. It is for discussion about development. Please don't wildly post all your compilation problems there. Ask on IRC for such issues.

IRC (Chat)

Most of the developers hang around in one development IRC channel or another. On freenode (irc.kde.org), you can find:

  • #KDE for the user questions.
  • #akonadi for development discussion on Akonadi.
  • #kontact for development discussion on Kontact and its components. Please don't post user-questions there.

There are a variety of IRC (Chat) programs available. KDE ships with Konversation. XChat is available in many installations as well.

Common KDE Developer information

Visit the KDE techbase site for very detailed information about KDE development. You'll find lots of stuff, e.g. documentation, tutorials, reference guides, etc.

http://techbase.kde.org/Projects/PIM has lots of informations you may read before starting contributing to KDE PIM.

http://userbase.kde.org/Kontact is the central place for user tips and tricks.

KDevelop is an Integrated Development Environment for KDE.

For recent news about KDE development you may not miss the KDE news site at dot.kde.org.

Prerequisites

You might want to make a backup of your valuable data, though. Most of it lives in .kde, in your home directory; You may also backup your Akonadi server config files in $HOME/.config/akonadi and your kdepim applications data in $HOME/.local/share/akonadi. It may be easier to just create an additional user and give it a copy of your data, and run PIM master there.

Git - a Source Code Control System

The KDE PIM repositories can be visited via web at http://cgit.kde.org

Compiling

KDE PIM is currently split to over 40 modules. To build them all in the correct order, one should use kdesrc-build.

If you already have kdesrc-build set up, you can skip the following part.

Setting up kdesrc-build

If you never user kdesrc-build before, you want to do at least an initial configuration to set where should kdesrc-build install the compiled binaries. The configuration is in .kdesrc-buildrc file in your home directory.

~/.kdesrc-buildrc:

global
    # KDE install directory
    kdedir /opt/kde-devel

    # Directory for downloaded source code
    source-dir ~/devel/KDE/

    # Directory to build KDE into before installing
    build-dir build

    # Use multiple cores for building. Other options to GNU make may also be
    # set.
    make-options -j4

    # Build with full debugging information
    cmake-options -DCMAKE_BUILD_TYPE=debugfull

end global

include /path/to/kdesrc-build/kf5-frameworks-build-include
include /path/to/kdesrc-build/kf5-kdepim-build-include
include /path/to/kdesrc-build/kf5-applications-build-include
include /path/to/kdesrc-build/kf5-workspace-build-include

You may want to customize some of the options above to fit your desired environment.

Setting up environment

Since the binaries will be installed to a non-standard location, you must adjust a few environment variables to point to the new location.

Here comes the important decision: you can either have a script that your source every time before running the development version of KDE PIM, or you can just add the environment settings to your ~/.bashrc and use the devleopment version of KDE PIM by default.

# This must match the path in kdedir option in kdesrc-buildrc
export KDE_PREFIX=/opt/kde-devel

export PATH="${KDE_PREFIX}/bin:${PATH:-/usr/local/bin:/usr/bin:/bin}"
export LD_LIBRARY_PATH="${KDE_PREFIX}/lib64:${KDE_PREFIX}/lib:$LD_LIBRARY_PATH"
export QT_PLUGIN_PATH="${KDE_PREFIX}/lib64/plugins:${KDE_PREFIX}/lib/plugins:${QT_PLUGIN_PATH:-/usr/lib64/qt5/plugins:/usr/lib/qt5/plugins}"
export QML2_IMPORT_PATH="${KDE_PREFIX}/lib64/qml:${KDE_PREFIX}/lib/qml:${QML2_IMPORT_PATH:-/usr/lib64/qt5/qml:/usr/lib/qt5/qml}"
export PKG_CONFIG_PATH="${KDE_PREFIX}/lib64/pkgconfig:${KDE_PREFIX}/lib/pkgconfig:${PKG_CONFIG_PATH:-/usr/lib64/pkgconfig:/usr/lib/pkgconfig}"
export XDG_DATA_DIRS="${KDE_PREFIX}/share:${XDG_DATA_DIRS:-/usr/share}"
export SASL_PATH="${KDE_PREFIX}/lib64/sasl2:${KDE_PREFIX}/lib/sasl2:${SASL_PATH:-/usr/lib64/sasl2:/usr/lib/sasl2}"
export XDG_CONFIG_DIRS="${KDE_PREFIX}/etc/xdg:${XDG_CONFIG_DIRS:-/etc/xdg}"

# Enable this if you want to have the devel version in parallel with the stable
#export AKONADI_INSTANCE=devel

Again, you may need to update some of the variables to fit your environment.

Compiling KDE PIM

KDE PIM depends on KDE Frameworks 5, Qt 5 and some additional libraries (like libical). If you distribution provides new-enough versions of all these libraries, you can compile KDE PIM against them, just make sure you have all the development packages for those libraries installed.

kdesrc-build kde-pimlibs kde-pim

If the build fails, you can check the log file to see why it failed. It will likely be because of a missing dependency.

Running KDE PIM

If you put the environment changes to your ~/.bashrc, you probably want to log out and back in to get the new environment applied globally. When you now run any KDE PIM app, it will start Akonadi all the KDE PIM apps from the new prefix. Otherwise you can just source the script in a terminal and run akonadictl --instance devel start. This will start a new instance of Akonadi which will run in parallel with the system one.