KDE TechBase - User contributions [en]

Development/Tutorials/Plasma/ContainmentAction

2013-03-09T11:22:49Z

Tstaerk: /* See also */

You can use Plasma ContainmentAction e.g. for Context Menus on your Plasma Desktop. They will run as plugins meaning you can add and remove them after compilation. If they exist, their name will be stored in [[Development/Tutorials/Desktop_File|.desktop files]]. ContainmentActions can only be written in C++ or QML, not in other Plasma programming languages, e.g. NOT in javascript.

= Example =
We will now create a simple example for Plasma ContainmentAction plugins. The code can be downloaded at https://github.com/tstaerk/kde-contextmenu/tree/tutorial. It creates a custom context menu that looks like this:

[[File:Snapshot-kde-contextmenu-2.png]]

The code is here:

== kde-contextmenu.desktop ==
[Desktop Entry]
Name=KDE Context Menu
Type=Service
Icon=favorites
Comment=Simple application launcher

ServiceTypes=Plasma/ContainmentActions

X-KDE-Library=kde-contextmenu
X-KDE-PluginInfo-Author=R. Hacker
X-KDE-PluginInfo-Email=hacker@home.org
X-KDE-PluginInfo-Name=kde-contextmenu
X-KDE-PluginInfo-Version=pre0.1
X-KDE-PluginInfo-Website=http://techbase.kde.org
X-KDE-PluginInfo-EnabledByDefault=true

The '''''Name''''' will show up later in this article when you select your context menu.

If you want to know which '''''ServiceTypes''''' exist, you can find out with the Linux command
ls `kde4-config --prefix`/share/kde4/servicetypes

== CMakeLists.txt ==
<pre>
project(kde-contextmenu)

set(KDE_MIN_VERSION "4.3.85") # for the < 4.2 macro
find_package(KDE4 4.3.85 REQUIRED)

include(MacroLibrary)
include(KDE4Defaults)

add_definitions(${QT_DEFINITIONS} ${KDE4_DEFINITIONS})
include_directories(${CMAKE_SOURCE_DIR} ${CMAKE_BINARY_DIR} ${KDE4_INCLUDES})

set(contextmenu_SRCS
launch.cpp
)

kde4_add_plugin(kde-contextmenu ${contextmenu_SRCS})
target_link_libraries(kde-contextmenu ${KDE4_PLASMA_LIBS} ${KDE4_KIO_LIBS})

install(TARGETS kde-contextmenu DESTINATION ${PLUGIN_INSTALL_DIR})
install(FILES kde-contextmenu.desktop DESTINATION ${SERVICES_INSTALL_DIR})
</pre>

== launch.h ==
<pre>
#ifndef CONTEXTMENU_HEADER
#define CONTEXTMENU_HEADER

#include <plasma/containmentactions.h>

class QAction;
class KMenu;

class ConTextMenu : public Plasma::ContainmentActions
{
Q_OBJECT
public:
ConTextMenu(QObject* parent, const QVariantList& args);
~ConTextMenu();

void init(const KConfigGroup &config);

void contextEvent(QEvent *event);
//returns true if something (other than a separator) was successfully added
bool addApps(QMenu *menu);

public slots:
void switchTo(QAction *action);

protected:
void makeMenu();

private:
KMenu *m_menu;
QAction *m_action;
};

K_EXPORT_PLASMA_CONTAINMENTACTIONS(favorites, ConTextMenu)

#endif
</pre>

== launch.cpp ==
<pre>
#include "launch.h"

#include <QGraphicsSceneMouseEvent>
#include <QGraphicsSceneWheelEvent>
#include <QFileInfo>

#include <KDebug>
#include <KIcon>
#include <KMenu>

#include <Plasma/DataEngine>
#include <Plasma/Containment>
#include <Plasma/Service>

ConTextMenu::ConTextMenu(QObject *parent, const QVariantList &args)
: Plasma::ContainmentActions(parent, args)
, m_action(new QAction(this))
{
m_menu = new KMenu();
connect(m_menu, SIGNAL(triggered(QAction*)), this, SLOT(switchTo(QAction*)));

m_action->setMenu(m_menu);
}

ConTextMenu::~ConTextMenu()
{
delete m_menu;
}

void ConTextMenu::init(const KConfigGroup &)
{
}

void ConTextMenu::contextEvent(QEvent *event)
{
makeMenu();
m_menu->adjustSize();
m_menu->exec(popupPosition(m_menu->size(), event));
}

void ConTextMenu::makeMenu()
{
m_menu->clear();
addApps(m_menu);
}

bool ConTextMenu::addApps(QMenu *menu)
{
QAction* action = menu->addAction(KIcon("system-run"), "Open a console");
action->setData("kde4-konsole.desktop");

action = menu->addAction(KIcon("firefox"), "Surf the web");
action->setData("firefox.desktop");

action = menu->addAction(KIcon("ksnapshot"), "Take a screenshot");
action->setData("kde4-ksnapshot.desktop");
return true;
}

void ConTextMenu::switchTo(QAction *action)
{
QString source = action->data().toString();
kDebug() << source;
Plasma::Service *service = dataEngine("apps")->serviceForSource(source);
if (service)
{
service->startOperationCall(service->operationDescription("launch"));
}
}

#include "launch.moc"
</pre>

== Install it ==
Compile, link and install it using the command
cmake -DCMAKE_INSTALL_PREFIX=`kde4-config --prefix` . && make -j8 && make install

== Test it ==
To test it, have your system re-discover its .desktop files by running the command
kbuildsycoca4
Then right-click onto your desktop, select "Folder View Settings" -> Mouse Actions and the context menu:

[[File:Snapshot-kde-contextmenu-1.png]]

Then click "Apply". You will see the config file ~/.kde4/share/config/plasma-desktop-appletsrc changes. Next time when you middle-click (or whatever you selected) onto your desktop, your own context menu will appear:

[[File:Snapshot-kde-contextmenu-2.png]]

= Debugging =
To debug your Plasma ContainmentAction call
kdebugdialog --fullmode
search for "plasma" and direct kDebug's output to /tmp/whatever.txt

= See also =
* [http://quickgit.kde.org/?p=kde-workspace.git&a=tree&f=plasma%2Fgeneric%2Fcontainmentactions Source code: ContainmentActions from kde-workspace]
* [http://www.staerk.de/thorsten/Kde-contextmenu kde-contextmenu's home page]

Development/Tutorials/Plasma/ContainmentAction

2013-03-06T19:19:57Z

Tstaerk: /* Test it */

Development/Tutorials/Plasma/ContainmentAction

2013-03-06T19:15:47Z

Tstaerk: /* kde-contextmenu.desktop */

You can use Plasma ContainmentAction e.g. for Context Menus on your Plasma Desktop. They will run as plugins meaning you can add and remove them after compilation. If they exist, their name will be stored in [[Development/Tutorials/Desktop_File|.desktop files]]. ContainmentActions can only be written in C++ or QML, not in other Plasma programming languages, e.g. NOT in javascript.

= Example =
We will now create a simple example for Plasma ContainmentAction plugins. The code can be downloaded at https://github.com/tstaerk/kde-contextmenu/tree/tutorial. It creates a custom context menu that looks like this:

[[File:Snapshot-kde-contextmenu-2.png]]

The code is here:

== kde-contextmenu.desktop ==
[Desktop Entry]
Name=KDE Context Menu
Type=Service
Icon=favorites
Comment=Simple application launcher

ServiceTypes=Plasma/ContainmentActions

X-KDE-Library=kde-contextmenu
X-KDE-PluginInfo-Author=R. Hacker
X-KDE-PluginInfo-Email=hacker@home.org
X-KDE-PluginInfo-Name=kde-contextmenu
X-KDE-PluginInfo-Version=pre0.1
X-KDE-PluginInfo-Website=http://techbase.kde.org
X-KDE-PluginInfo-EnabledByDefault=true

The '''''Name''''' will show up later in this article when you select your context menu.

If you want to know which '''''ServiceTypes''''' exist, you can find out with the Linux command
ls `kde4-config --prefix`/share/kde4/servicetypes

== CMakeLists.txt ==
<pre>
project(kde-contextmenu)

set(KDE_MIN_VERSION "4.3.85") # for the < 4.2 macro
find_package(KDE4 4.3.85 REQUIRED)

include(MacroLibrary)
include(KDE4Defaults)

add_definitions(${QT_DEFINITIONS} ${KDE4_DEFINITIONS})
include_directories(${CMAKE_SOURCE_DIR} ${CMAKE_BINARY_DIR} ${KDE4_INCLUDES})

set(contextmenu_SRCS
launch.cpp
)

kde4_add_plugin(kde-contextmenu ${contextmenu_SRCS})
target_link_libraries(kde-contextmenu ${KDE4_PLASMA_LIBS} ${KDE4_KIO_LIBS})

install(TARGETS kde-contextmenu DESTINATION ${PLUGIN_INSTALL_DIR})
install(FILES kde-contextmenu.desktop DESTINATION ${SERVICES_INSTALL_DIR})
</pre>

== launch.h ==
<pre>
#ifndef CONTEXTMENU_HEADER
#define CONTEXTMENU_HEADER

#include <plasma/containmentactions.h>

class QAction;
class KMenu;

class ConTextMenu : public Plasma::ContainmentActions
{
Q_OBJECT
public:
ConTextMenu(QObject* parent, const QVariantList& args);
~ConTextMenu();

void init(const KConfigGroup &config);

void contextEvent(QEvent *event);
//returns true if something (other than a separator) was successfully added
bool addApps(QMenu *menu);

public slots:
void switchTo(QAction *action);

protected:
void makeMenu();

private:
KMenu *m_menu;
QAction *m_action;
};

K_EXPORT_PLASMA_CONTAINMENTACTIONS(favorites, ConTextMenu)

#endif
</pre>

== launch.cpp ==
<pre>
#include "launch.h"

#include <QGraphicsSceneMouseEvent>
#include <QGraphicsSceneWheelEvent>
#include <QFileInfo>

#include <KDebug>
#include <KIcon>
#include <KMenu>

#include <Plasma/DataEngine>
#include <Plasma/Containment>
#include <Plasma/Service>

ConTextMenu::ConTextMenu(QObject *parent, const QVariantList &args)
: Plasma::ContainmentActions(parent, args)
, m_action(new QAction(this))
{
m_menu = new KMenu();
connect(m_menu, SIGNAL(triggered(QAction*)), this, SLOT(switchTo(QAction*)));

m_action->setMenu(m_menu);
}

ConTextMenu::~ConTextMenu()
{
delete m_menu;
}

void ConTextMenu::init(const KConfigGroup &)
{
}

void ConTextMenu::contextEvent(QEvent *event)
{
makeMenu();
m_menu->adjustSize();
m_menu->exec(popupPosition(m_menu->size(), event));
}

void ConTextMenu::makeMenu()
{
m_menu->clear();
addApps(m_menu);
}

bool ConTextMenu::addApps(QMenu *menu)
{
QAction* action = menu->addAction(KIcon("system-run"), "Open a console");
action->setData("kde4-konsole.desktop");

action = menu->addAction(KIcon("firefox"), "Surf the web");
action->setData("firefox.desktop");

action = menu->addAction(KIcon("ksnapshot"), "Take a screenshot");
action->setData("kde4-ksnapshot.desktop");
return true;
}

void ConTextMenu::switchTo(QAction *action)
{
QString source = action->data().toString();
kDebug() << source;
Plasma::Service *service = dataEngine("apps")->serviceForSource(source);
if (service)
{
service->startOperationCall(service->operationDescription("launch"));
}
}

#include "launch.moc"
</pre>

== Install it ==
Compile, link and install it using the command
cmake -DCMAKE_INSTALL_PREFIX=`kde4-config --prefix` . && make -j8 && make install

== Test it ==
To test it, have your system re-discover its .desktop files by running the command
kbuildsycoca4
Then right-click onto your desktop, select "Folder View Settings" -> Mouse Actions and the context menu:

[[File:Snapshot-kde-contextmenu-1.png]]

Then click "Apply". Next time you middle-click (or whatever you selected) onto your desktop, your own context menu will appear:

[[File:Snapshot-kde-contextmenu-2.png]]

= Debugging =
To debug your Plasma ContainmentAction call
kdebugdialog --fullmode
search for "plasma" and direct kDebug's output to /tmp/whatever.txt

= See also =
* [http://quickgit.kde.org/?p=kde-workspace.git&a=tree&f=plasma%2Fgeneric%2Fcontainmentactions ContainmentActions from kde-workspace]

Development/Tutorials/Plasma/ContainmentAction

2013-03-06T19:10:26Z

Tstaerk: /* kde-contextmenu.desktop */

You can use Plasma ContainmentAction e.g. for Context Menus on your Plasma Desktop. They will run as plugins meaning you can add and remove them after compilation. If they exist, their name will be stored in [[Development/Tutorials/Desktop_File|.desktop files]]. ContainmentActions can only be written in C++ or QML, not in other Plasma programming languages, e.g. NOT in javascript.

= Example =
We will now create a simple example for Plasma ContainmentAction plugins. The code can be downloaded at https://github.com/tstaerk/kde-contextmenu/tree/tutorial. It creates a custom context menu that looks like this:

[[File:Snapshot-kde-contextmenu-2.png]]

The code is here:

== kde-contextmenu.desktop ==
[Desktop Entry]
Name=KDE Context Menu
Type=Service
Icon=favorites
Comment=Simple application launcher

ServiceTypes=Plasma/ContainmentActions

X-KDE-Library=kde-contextmenu
X-KDE-PluginInfo-Author=R. Hacker
X-KDE-PluginInfo-Email=hacker@home.org
X-KDE-PluginInfo-Name=kde-contextmenu
X-KDE-PluginInfo-Version=pre0.1
X-KDE-PluginInfo-Website=http://techbase.kde.org
X-KDE-PluginInfo-EnabledByDefault=true

If you want to know which '''''ServiceTypes''''' exist, you can find out with the Linux command
ls `kde4-config --prefix`/share/kde4/servicetypes

== CMakeLists.txt ==
<pre>
project(kde-contextmenu)

set(KDE_MIN_VERSION "4.3.85") # for the < 4.2 macro
find_package(KDE4 4.3.85 REQUIRED)

include(MacroLibrary)
include(KDE4Defaults)

add_definitions(${QT_DEFINITIONS} ${KDE4_DEFINITIONS})
include_directories(${CMAKE_SOURCE_DIR} ${CMAKE_BINARY_DIR} ${KDE4_INCLUDES})

set(contextmenu_SRCS
launch.cpp
)

kde4_add_plugin(kde-contextmenu ${contextmenu_SRCS})
target_link_libraries(kde-contextmenu ${KDE4_PLASMA_LIBS} ${KDE4_KIO_LIBS})

install(TARGETS kde-contextmenu DESTINATION ${PLUGIN_INSTALL_DIR})
install(FILES kde-contextmenu.desktop DESTINATION ${SERVICES_INSTALL_DIR})
</pre>

== launch.h ==
<pre>
#ifndef CONTEXTMENU_HEADER
#define CONTEXTMENU_HEADER

#include <plasma/containmentactions.h>

class QAction;
class KMenu;

class ConTextMenu : public Plasma::ContainmentActions
{
Q_OBJECT
public:
ConTextMenu(QObject* parent, const QVariantList& args);
~ConTextMenu();

void init(const KConfigGroup &config);

void contextEvent(QEvent *event);
//returns true if something (other than a separator) was successfully added
bool addApps(QMenu *menu);

public slots:
void switchTo(QAction *action);

protected:
void makeMenu();

private:
KMenu *m_menu;
QAction *m_action;
};

K_EXPORT_PLASMA_CONTAINMENTACTIONS(favorites, ConTextMenu)

#endif
</pre>

== launch.cpp ==
<pre>
#include "launch.h"

#include <QGraphicsSceneMouseEvent>
#include <QGraphicsSceneWheelEvent>
#include <QFileInfo>

#include <KDebug>
#include <KIcon>
#include <KMenu>

#include <Plasma/DataEngine>
#include <Plasma/Containment>
#include <Plasma/Service>

ConTextMenu::ConTextMenu(QObject *parent, const QVariantList &args)
: Plasma::ContainmentActions(parent, args)
, m_action(new QAction(this))
{
m_menu = new KMenu();
connect(m_menu, SIGNAL(triggered(QAction*)), this, SLOT(switchTo(QAction*)));

m_action->setMenu(m_menu);
}

ConTextMenu::~ConTextMenu()
{
delete m_menu;
}

void ConTextMenu::init(const KConfigGroup &)
{
}

void ConTextMenu::contextEvent(QEvent *event)
{
makeMenu();
m_menu->adjustSize();
m_menu->exec(popupPosition(m_menu->size(), event));
}

void ConTextMenu::makeMenu()
{
m_menu->clear();
addApps(m_menu);
}

bool ConTextMenu::addApps(QMenu *menu)
{
QAction* action = menu->addAction(KIcon("system-run"), "Open a console");
action->setData("kde4-konsole.desktop");

action = menu->addAction(KIcon("firefox"), "Surf the web");
action->setData("firefox.desktop");

action = menu->addAction(KIcon("ksnapshot"), "Take a screenshot");
action->setData("kde4-ksnapshot.desktop");
return true;
}

void ConTextMenu::switchTo(QAction *action)
{
QString source = action->data().toString();
kDebug() << source;
Plasma::Service *service = dataEngine("apps")->serviceForSource(source);
if (service)
{
service->startOperationCall(service->operationDescription("launch"));
}
}

#include "launch.moc"
</pre>

== Install it ==
Compile, link and install it using the command
cmake -DCMAKE_INSTALL_PREFIX=`kde4-config --prefix` . && make -j8 && make install

== Test it ==
To test it, have your system re-discover its .desktop files by running the command
kbuildsycoca4
Then right-click onto your desktop, select "Folder View Settings" -> Mouse Actions and the context menu:

[[File:Snapshot-kde-contextmenu-1.png]]

Then click "Apply". Next time you middle-click (or whatever you selected) onto your desktop, your own context menu will appear:

[[File:Snapshot-kde-contextmenu-2.png]]

= Debugging =
To debug your Plasma ContainmentAction call
kdebugdialog --fullmode
search for "plasma" and direct kDebug's output to /tmp/whatever.txt

= See also =
* [http://quickgit.kde.org/?p=kde-workspace.git&a=tree&f=plasma%2Fgeneric%2Fcontainmentactions ContainmentActions from kde-workspace]

Development/Tutorials/Plasma/ContainmentAction

2013-03-06T19:00:54Z

Tstaerk:

You can use Plasma ContainmentAction e.g. for Context Menus on your Plasma Desktop. They will run as plugins meaning you can add and remove them after compilation. If they exist, their name will be stored in [[Development/Tutorials/Desktop_File|.desktop files]]. ContainmentActions can only be written in C++ or QML, not in other Plasma programming languages, e.g. NOT in javascript.

= Example =
We will now create a simple example for Plasma ContainmentAction plugins. The code can be downloaded at https://github.com/tstaerk/kde-contextmenu/tree/tutorial. It creates a custom context menu that looks like this:

[[File:Snapshot-kde-contextmenu-2.png]]

The code is here:

== kde-contextmenu.desktop ==
[Desktop Entry]
Name=KDE Context Menu
Type=Service
Icon=favorites
Comment=Simple application launcher

ServiceTypes=Plasma/ContainmentActions

X-KDE-Library=kde-contextmenu
X-KDE-PluginInfo-Author=R. Hacker
X-KDE-PluginInfo-Email=hacker@home.org
X-KDE-PluginInfo-Name=kde-contextmenu
X-KDE-PluginInfo-Version=pre0.1
X-KDE-PluginInfo-Website=http://techbase.kde.org
X-KDE-PluginInfo-EnabledByDefault=true

== CMakeLists.txt ==
<pre>
project(kde-contextmenu)

set(KDE_MIN_VERSION "4.3.85") # for the < 4.2 macro
find_package(KDE4 4.3.85 REQUIRED)

include(MacroLibrary)
include(KDE4Defaults)

add_definitions(${QT_DEFINITIONS} ${KDE4_DEFINITIONS})
include_directories(${CMAKE_SOURCE_DIR} ${CMAKE_BINARY_DIR} ${KDE4_INCLUDES})

set(contextmenu_SRCS
launch.cpp
)

kde4_add_plugin(kde-contextmenu ${contextmenu_SRCS})
target_link_libraries(kde-contextmenu ${KDE4_PLASMA_LIBS} ${KDE4_KIO_LIBS})

install(TARGETS kde-contextmenu DESTINATION ${PLUGIN_INSTALL_DIR})
install(FILES kde-contextmenu.desktop DESTINATION ${SERVICES_INSTALL_DIR})
</pre>

== launch.h ==
<pre>
#ifndef CONTEXTMENU_HEADER
#define CONTEXTMENU_HEADER

#include <plasma/containmentactions.h>

class QAction;
class KMenu;

class ConTextMenu : public Plasma::ContainmentActions
{
Q_OBJECT
public:
ConTextMenu(QObject* parent, const QVariantList& args);
~ConTextMenu();

void init(const KConfigGroup &config);

void contextEvent(QEvent *event);
//returns true if something (other than a separator) was successfully added
bool addApps(QMenu *menu);

public slots:
void switchTo(QAction *action);

protected:
void makeMenu();

private:
KMenu *m_menu;
QAction *m_action;
};

K_EXPORT_PLASMA_CONTAINMENTACTIONS(favorites, ConTextMenu)

#endif
</pre>

== launch.cpp ==
<pre>
#include "launch.h"

#include <QGraphicsSceneMouseEvent>
#include <QGraphicsSceneWheelEvent>
#include <QFileInfo>

#include <KDebug>
#include <KIcon>
#include <KMenu>

#include <Plasma/DataEngine>
#include <Plasma/Containment>
#include <Plasma/Service>

ConTextMenu::ConTextMenu(QObject *parent, const QVariantList &args)
: Plasma::ContainmentActions(parent, args)
, m_action(new QAction(this))
{
m_menu = new KMenu();
connect(m_menu, SIGNAL(triggered(QAction*)), this, SLOT(switchTo(QAction*)));

m_action->setMenu(m_menu);
}

ConTextMenu::~ConTextMenu()
{
delete m_menu;
}

void ConTextMenu::init(const KConfigGroup &)
{
}

void ConTextMenu::contextEvent(QEvent *event)
{
makeMenu();
m_menu->adjustSize();
m_menu->exec(popupPosition(m_menu->size(), event));
}

void ConTextMenu::makeMenu()
{
m_menu->clear();
addApps(m_menu);
}

bool ConTextMenu::addApps(QMenu *menu)
{
QAction* action = menu->addAction(KIcon("system-run"), "Open a console");
action->setData("kde4-konsole.desktop");

action = menu->addAction(KIcon("firefox"), "Surf the web");
action->setData("firefox.desktop");

action = menu->addAction(KIcon("ksnapshot"), "Take a screenshot");
action->setData("kde4-ksnapshot.desktop");
return true;
}

void ConTextMenu::switchTo(QAction *action)
{
QString source = action->data().toString();
kDebug() << source;
Plasma::Service *service = dataEngine("apps")->serviceForSource(source);
if (service)
{
service->startOperationCall(service->operationDescription("launch"));
}
}

#include "launch.moc"
</pre>

== Install it ==
Compile, link and install it using the command
cmake -DCMAKE_INSTALL_PREFIX=`kde4-config --prefix` . && make -j8 && make install

== Test it ==
To test it, have your system re-discover its .desktop files by running the command
kbuildsycoca4
Then right-click onto your desktop, select "Folder View Settings" -> Mouse Actions and the context menu:

[[File:Snapshot-kde-contextmenu-1.png]]

Then click "Apply". Next time you middle-click (or whatever you selected) onto your desktop, your own context menu will appear:

[[File:Snapshot-kde-contextmenu-2.png]]

= Debugging =
To debug your Plasma ContainmentAction call
kdebugdialog --fullmode
search for "plasma" and direct kDebug's output to /tmp/whatever.txt

= See also =
* [http://quickgit.kde.org/?p=kde-workspace.git&a=tree&f=plasma%2Fgeneric%2Fcontainmentactions ContainmentActions from kde-workspace]

Development/Tutorials/Plasma/ContainmentAction

2013-03-04T13:35:22Z

Tstaerk: run kbuildsycoca or you do not have a guarantee that the .desktop file will be discovered

You can use Plasma ContainmentAction e.g. for Context Menus on your Plasma Desktop. They will run as plugins meaning you can add and remove them after compilation. If they exist, their name will be stored in [[Development/Tutorials/Desktop_File|.desktop files]].

= Example =
We will now create a simple example for Plasma ContainmentAction plugins. The code can be downloaded at https://github.com/tstaerk/kde-contextmenu/tree/tutorial. It creates a custom context menu that looks like this:

[[File:Snapshot-kde-contextmenu-2.png]]

The code is here:

== kde-contextmenu.desktop ==
[Desktop Entry]
Name=KDE Context Menu
Type=Service
Icon=favorites
Comment=Simple application launcher

ServiceTypes=Plasma/ContainmentActions

X-KDE-Library=kde-contextmenu
X-KDE-PluginInfo-Author=R. Hacker
X-KDE-PluginInfo-Email=hacker@home.org
X-KDE-PluginInfo-Name=kde-contextmenu
X-KDE-PluginInfo-Version=pre0.1
X-KDE-PluginInfo-Website=http://techbase.kde.org
X-KDE-PluginInfo-EnabledByDefault=true

== CMakeLists.txt ==
<pre>
project(kde-contextmenu)

set(KDE_MIN_VERSION "4.3.85") # for the < 4.2 macro
find_package(KDE4 4.3.85 REQUIRED)

include(MacroLibrary)
include(KDE4Defaults)

add_definitions(${QT_DEFINITIONS} ${KDE4_DEFINITIONS})
include_directories(${CMAKE_SOURCE_DIR} ${CMAKE_BINARY_DIR} ${KDE4_INCLUDES})

set(contextmenu_SRCS
launch.cpp
)

kde4_add_plugin(kde-contextmenu ${contextmenu_SRCS})
target_link_libraries(kde-contextmenu ${KDE4_PLASMA_LIBS} ${KDE4_KIO_LIBS})

install(TARGETS kde-contextmenu DESTINATION ${PLUGIN_INSTALL_DIR})
install(FILES kde-contextmenu.desktop DESTINATION ${SERVICES_INSTALL_DIR})
</pre>

== launch.h ==
<pre>
#ifndef CONTEXTMENU_HEADER
#define CONTEXTMENU_HEADER

#include <plasma/containmentactions.h>

class QAction;
class KMenu;

class ConTextMenu : public Plasma::ContainmentActions
{
Q_OBJECT
public:
ConTextMenu(QObject* parent, const QVariantList& args);
~ConTextMenu();

void init(const KConfigGroup &config);

void contextEvent(QEvent *event);
//returns true if something (other than a separator) was successfully added
bool addApps(QMenu *menu);

public slots:
void switchTo(QAction *action);

protected:
void makeMenu();

private:
KMenu *m_menu;
QAction *m_action;
};

K_EXPORT_PLASMA_CONTAINMENTACTIONS(favorites, ConTextMenu)

#endif
</pre>

== launch.cpp ==
<pre>
#include "launch.h"

#include <QGraphicsSceneMouseEvent>
#include <QGraphicsSceneWheelEvent>
#include <QFileInfo>

#include <KDebug>
#include <KIcon>
#include <KMenu>

#include <Plasma/DataEngine>
#include <Plasma/Containment>
#include <Plasma/Service>

ConTextMenu::ConTextMenu(QObject *parent, const QVariantList &args)
: Plasma::ContainmentActions(parent, args)
, m_action(new QAction(this))
{
m_menu = new KMenu();
connect(m_menu, SIGNAL(triggered(QAction*)), this, SLOT(switchTo(QAction*)));

m_action->setMenu(m_menu);
}

ConTextMenu::~ConTextMenu()
{
delete m_menu;
}

void ConTextMenu::init(const KConfigGroup &)
{
}

void ConTextMenu::contextEvent(QEvent *event)
{
makeMenu();
m_menu->adjustSize();
m_menu->exec(popupPosition(m_menu->size(), event));
}

void ConTextMenu::makeMenu()
{
m_menu->clear();
addApps(m_menu);
}

bool ConTextMenu::addApps(QMenu *menu)
{
QAction* action = menu->addAction(KIcon("system-run"), "Open a console");
action->setData("kde4-konsole.desktop");

action = menu->addAction(KIcon("firefox"), "Surf the web");
action->setData("firefox.desktop");

action = menu->addAction(KIcon("ksnapshot"), "Take a screenshot");
action->setData("kde4-ksnapshot.desktop");
return true;
}

void ConTextMenu::switchTo(QAction *action)
{
QString source = action->data().toString();
kDebug() << source;
Plasma::Service *service = dataEngine("apps")->serviceForSource(source);
if (service)
{
service->startOperationCall(service->operationDescription("launch"));
}
}

#include "launch.moc"
</pre>

== Install it ==
Compile, link and install it using the command
cmake -DCMAKE_INSTALL_PREFIX=`kde4-config --prefix` . && make -j8 && make install

== Test it ==
To test it, have your system re-discover its .desktop files by running the command
kbuildsycoca4
Then right-click onto your desktop, select "Folder View Settings" -> Mouse Actions and the context menu:

[[File:Snapshot-kde-contextmenu-1.png]]

Then click "Apply". Next time you middle-click (or whatever you selected) onto your desktop, your own context menu will appear:

[[File:Snapshot-kde-contextmenu-2.png]]

= Debugging =
To debug your Plasma ContainmentAction call
kdebugdialog --fullmode
search for "plasma" and direct kDebug's output to /tmp/whatever.txt

= See also =
* [http://quickgit.kde.org/?p=kde-workspace.git&a=tree&f=plasma%2Fgeneric%2Fcontainmentactions ContainmentActions from kde-workspace]

Development/Tutorials/Plasma/ContainmentAction

2013-03-01T15:17:23Z

Tstaerk: /* Example */

You can use Plasma ContainmentAction e.g. for Context Menus on your Plasma Desktop. They will run as plugins meaning you can add and remove them after compilation. If they exist, their name will be stored in [[Development/Tutorials/Desktop_File|.desktop files]].

= Example =
We will now create a simple example for Plasma ContainmentAction plugins. The code can be downloaded at https://github.com/tstaerk/kde-contextmenu/tree/tutorial. It creates a custom context menu that looks like this:

[[File:Snapshot-kde-contextmenu-2.png]]

The code is here:

== kde-contextmenu.desktop ==
[Desktop Entry]
Name=KDE Context Menu
Type=Service
Icon=favorites
Comment=Simple application launcher

ServiceTypes=Plasma/ContainmentActions

X-KDE-Library=kde-contextmenu
X-KDE-PluginInfo-Author=R. Hacker
X-KDE-PluginInfo-Email=hacker@home.org
X-KDE-PluginInfo-Name=kde-contextmenu
X-KDE-PluginInfo-Version=pre0.1
X-KDE-PluginInfo-Website=http://techbase.kde.org
X-KDE-PluginInfo-EnabledByDefault=true

== CMakeLists.txt ==
<pre>
project(kde-contextmenu)

set(KDE_MIN_VERSION "4.3.85") # for the < 4.2 macro
find_package(KDE4 4.3.85 REQUIRED)

include(MacroLibrary)
include(KDE4Defaults)

add_definitions(${QT_DEFINITIONS} ${KDE4_DEFINITIONS})
include_directories(${CMAKE_SOURCE_DIR} ${CMAKE_BINARY_DIR} ${KDE4_INCLUDES})

set(contextmenu_SRCS
launch.cpp
)

kde4_add_plugin(kde-contextmenu ${contextmenu_SRCS})
target_link_libraries(kde-contextmenu ${KDE4_PLASMA_LIBS} ${KDE4_KIO_LIBS})

install(TARGETS kde-contextmenu DESTINATION ${PLUGIN_INSTALL_DIR})
install(FILES kde-contextmenu.desktop DESTINATION ${SERVICES_INSTALL_DIR})
</pre>

== launch.h ==
<pre>
#ifndef CONTEXTMENU_HEADER
#define CONTEXTMENU_HEADER

#include <plasma/containmentactions.h>

class QAction;
class KMenu;

class ConTextMenu : public Plasma::ContainmentActions
{
Q_OBJECT
public:
ConTextMenu(QObject* parent, const QVariantList& args);
~ConTextMenu();

void init(const KConfigGroup &config);

void contextEvent(QEvent *event);
//returns true if something (other than a separator) was successfully added
bool addApps(QMenu *menu);

public slots:
void switchTo(QAction *action);

protected:
void makeMenu();

private:
KMenu *m_menu;
QAction *m_action;
};

K_EXPORT_PLASMA_CONTAINMENTACTIONS(favorites, ConTextMenu)

#endif
</pre>

== launch.cpp ==
<pre>
#include "launch.h"

#include <QGraphicsSceneMouseEvent>
#include <QGraphicsSceneWheelEvent>
#include <QFileInfo>

#include <KDebug>
#include <KIcon>
#include <KMenu>

#include <Plasma/DataEngine>
#include <Plasma/Containment>
#include <Plasma/Service>

ConTextMenu::ConTextMenu(QObject *parent, const QVariantList &args)
: Plasma::ContainmentActions(parent, args)
, m_action(new QAction(this))
{
m_menu = new KMenu();
connect(m_menu, SIGNAL(triggered(QAction*)), this, SLOT(switchTo(QAction*)));

m_action->setMenu(m_menu);
}

ConTextMenu::~ConTextMenu()
{
delete m_menu;
}

void ConTextMenu::init(const KConfigGroup &)
{
}

void ConTextMenu::contextEvent(QEvent *event)
{
makeMenu();
m_menu->adjustSize();
m_menu->exec(popupPosition(m_menu->size(), event));
}

void ConTextMenu::makeMenu()
{
m_menu->clear();
addApps(m_menu);
}

bool ConTextMenu::addApps(QMenu *menu)
{
QAction* action = menu->addAction(KIcon("system-run"), "Open a console");
action->setData("kde4-konsole.desktop");

action = menu->addAction(KIcon("firefox"), "Surf the web");
action->setData("firefox.desktop");

action = menu->addAction(KIcon("ksnapshot"), "Take a screenshot");
action->setData("kde4-ksnapshot.desktop");
return true;
}

void ConTextMenu::switchTo(QAction *action)
{
QString source = action->data().toString();
kDebug() << source;
Plasma::Service *service = dataEngine("apps")->serviceForSource(source);
if (service)
{
service->startOperationCall(service->operationDescription("launch"));
}
}

#include "launch.moc"
</pre>

== Install it ==
Compile, link and install it using the command
cmake -DCMAKE_INSTALL_PREFIX=`kde4-config --prefix` . && make -j8 && make install

== Test it ==
To test it, right-click onto your desktop and select "Folder View Settings". Then select Mouse Actions and the context menu:

[[File:Snapshot-kde-contextmenu-1.png]]

Then click "Apply". Next time you middle-click (or whatever you selected) onto your desktop, your own context menu will appear:

[[File:Snapshot-kde-contextmenu-2.png]]

= Debugging =
To debug your Plasma ContainmentAction call
kdebugdialog --fullmode
search for "plasma" and direct kDebug's output to /tmp/whatever.txt

= See also =
* [http://quickgit.kde.org/?p=kde-workspace.git&a=tree&f=plasma%2Fgeneric%2Fcontainmentactions ContainmentActions from kde-workspace]

Development/Tutorials/Plasma/ContainmentAction

2013-03-01T15:07:52Z

Tstaerk: /* launch.cpp */

You can use Plasma ContainmentAction e.g. for Context Menus on your Plasma Desktop. They will run as plugins meaning you can add and remove them after compilation. If they exist, their name will be stored in [[Development/Tutorials/Desktop_File|.desktop files]].

= Example =
A simple example for Plasma ContainmentAction plugins can be found at https://github.com/tstaerk/kde-contextmenu/tree/0.1. Let's look at it here:

== kde-contextmenu.desktop ==
[Desktop Entry]
Name=KDE Context Menu
Type=Service
Icon=favorites
Comment=Simple application launcher

ServiceTypes=Plasma/ContainmentActions

X-KDE-Library=kde-contextmenu
X-KDE-PluginInfo-Author=R. Hacker
X-KDE-PluginInfo-Email=hacker@home.org
X-KDE-PluginInfo-Name=kde-contextmenu
X-KDE-PluginInfo-Version=pre0.1
X-KDE-PluginInfo-Website=http://techbase.kde.org
X-KDE-PluginInfo-EnabledByDefault=true

== CMakeLists.txt ==
<pre>
project(kde-contextmenu)

set(KDE_MIN_VERSION "4.3.85") # for the < 4.2 macro
find_package(KDE4 4.3.85 REQUIRED)

include(MacroLibrary)
include(KDE4Defaults)

add_definitions(${QT_DEFINITIONS} ${KDE4_DEFINITIONS})
include_directories(${CMAKE_SOURCE_DIR} ${CMAKE_BINARY_DIR} ${KDE4_INCLUDES})

set(contextmenu_SRCS
launch.cpp
)

kde4_add_plugin(kde-contextmenu ${contextmenu_SRCS})
target_link_libraries(kde-contextmenu ${KDE4_PLASMA_LIBS} ${KDE4_KIO_LIBS})

install(TARGETS kde-contextmenu DESTINATION ${PLUGIN_INSTALL_DIR})
install(FILES kde-contextmenu.desktop DESTINATION ${SERVICES_INSTALL_DIR})
</pre>

== launch.h ==
<pre>
#ifndef CONTEXTMENU_HEADER
#define CONTEXTMENU_HEADER

#include <plasma/containmentactions.h>

class QAction;
class KMenu;

class ConTextMenu : public Plasma::ContainmentActions
{
Q_OBJECT
public:
ConTextMenu(QObject* parent, const QVariantList& args);
~ConTextMenu();

void init(const KConfigGroup &config);

void contextEvent(QEvent *event);
//returns true if something (other than a separator) was successfully added
bool addApps(QMenu *menu);

public slots:
void switchTo(QAction *action);

protected:
void makeMenu();

private:
KMenu *m_menu;
QAction *m_action;
};

K_EXPORT_PLASMA_CONTAINMENTACTIONS(favorites, ConTextMenu)

#endif
</pre>

== launch.cpp ==
<pre>
#include "launch.h"

#include <QGraphicsSceneMouseEvent>
#include <QGraphicsSceneWheelEvent>
#include <QFileInfo>

#include <KDebug>
#include <KIcon>
#include <KMenu>

#include <Plasma/DataEngine>
#include <Plasma/Containment>
#include <Plasma/Service>

ConTextMenu::ConTextMenu(QObject *parent, const QVariantList &args)
: Plasma::ContainmentActions(parent, args)
, m_action(new QAction(this))
{
m_menu = new KMenu();
connect(m_menu, SIGNAL(triggered(QAction*)), this, SLOT(switchTo(QAction*)));

m_action->setMenu(m_menu);
}

ConTextMenu::~ConTextMenu()
{
delete m_menu;
}

void ConTextMenu::init(const KConfigGroup &)
{
}

void ConTextMenu::contextEvent(QEvent *event)
{
makeMenu();
m_menu->adjustSize();
m_menu->exec(popupPosition(m_menu->size(), event));
}

void ConTextMenu::makeMenu()
{
m_menu->clear();
addApps(m_menu);
}

bool ConTextMenu::addApps(QMenu *menu)
{
QAction* action = menu->addAction(KIcon("system-run"), "Open a console");
action->setData("kde4-konsole.desktop");

action = menu->addAction(KIcon("firefox"), "Surf the web");
action->setData("firefox.desktop");

action = menu->addAction(KIcon("ksnapshot"), "Take a screenshot");
action->setData("kde4-ksnapshot.desktop");
return true;
}

void ConTextMenu::switchTo(QAction *action)
{
QString source = action->data().toString();
kDebug() << source;
Plasma::Service *service = dataEngine("apps")->serviceForSource(source);
if (service)
{
service->startOperationCall(service->operationDescription("launch"));
}
}

#include "launch.moc"
</pre>

== Install it ==
Compile, link and install it using the command
cmake -DCMAKE_INSTALL_PREFIX=`kde4-config --prefix` . && make -j8 && make install

== Test it ==
To test it, right-click onto your desktop and select "Folder View Settings". Then select Mouse Actions and the context menu:

[[File:Snapshot-kde-contextmenu-1.png]]

Then click "Apply". Next time you middle-click (or whatever you selected) onto your desktop, your own context menu will appear:

[[File:Snapshot-kde-contextmenu-2.png]]

= Debugging =
To debug your Plasma ContainmentAction call
kdebugdialog --fullmode
search for "plasma" and direct kDebug's output to /tmp/whatever.txt

= See also =
* [http://quickgit.kde.org/?p=kde-workspace.git&a=tree&f=plasma%2Fgeneric%2Fcontainmentactions ContainmentActions from kde-workspace]

Development/Tutorials/Plasma/ContainmentAction

2013-03-01T15:06:22Z

Tstaerk: launch.h

Development/Tutorials/Plasma/ContainmentAction

2013-03-01T00:31:22Z

Tstaerk: /* Test it */

Development/Tutorials/Plasma/ContainmentAction

2013-03-01T00:30:10Z

Tstaerk: /* Test it */

File:Snapshot-kde-contextmenu-2.png

2013-03-01T00:28:34Z

Tstaerk: showing the contextmenu from the Plasma ContainmentActions plugin tutorial

showing the contextmenu from the Plasma ContainmentActions plugin tutorial

Development/Tutorials/Plasma/ContainmentAction

2013-03-01T00:22:49Z

Tstaerk: test it

File:Snapshot-kde-contextmenu-1.png

2013-03-01T00:21:20Z

Tstaerk: Belongs to the tutorial how to program a Plasma ContainmentActions Plugin. Shows how to select one.

Belongs to the tutorial how to program a Plasma ContainmentActions Plugin. Shows how to select one.

Development/Tutorials/Plasma/ContainmentAction

2013-03-01T00:10:57Z

Tstaerk: compilation

Development/Tutorials/Plasma/ContainmentAction

2013-03-01T00:05:18Z

Tstaerk:

Development/Tutorials/Plasma/ContainmentAction

2013-02-28T23:15:06Z

Tstaerk: CMakeLists.txt

Development/Tutorials/Plasma/ContainmentAction

2013-02-28T23:10:37Z

Tstaerk:

Development/Tutorials/Plasma/ContainmentAction

2013-02-28T22:46:33Z

Tstaerk:

Development/Tutorials/Plasma/ContainmentAction

2013-02-28T22:18:10Z

Tstaerk: debugging

= Debugging =
To debug your Plasma ContainmentAction call
kdebugdialog --fullmode
search for "plasma" and direct kDebug's output to /tmp/whatever.txt

Development/Tutorials/Plasma

2013-02-28T22:14:49Z

Tstaerk: plasma containment actions

== QML ==
Plasmoids that use the QML (aka QtQuick) declarative language to describe their user interface while having the logic of the applet, in JavaScript (QML is essentially a forge between CSS and JavaScript).

This is now the '''recommended''' method of creating plasmoids, where possible. The plasmoid, or applet serves as the visualization for the data which a Plasma::DataEngine contains.

It allows easily the declaring of an interface and to easily create things like ListViews with native Plasma theming. It is what Plasma is leaning the most towards, especially in the Mobile, MediaCenter shells.

;[[Development/Tutorials/Plasma/QML/GettingStarted|Getting Started]]
:''Creating and running your first plasmoid in QML''

;[[Development/Tutorials/Plasma/QML/Basic_ListView|Basic List Plasmoid]]
:''Make a QML ListView which displays basic text objects as items. Utilizes native Plasma theming and animations.''

;[[Development/Tutorials/Plasma/QML/API|API Reference]]
:''The QML Plasmoid API. Useful for referencing what is available in the runtime, what are the differences with the pure JavaScript ScriptEngine, the differences between pure Qt QML and Plasma, and as a study aid for the tutorials above.''

== C++ ==

=== Plasmoids ===
;[[Development/Tutorials/Plasma/GettingStarted|Getting Started With Plasmoids]]
:''Creating your first plasmoid in C++ with SVG background, icon and text''

;[[Development/Tutorials/Plasma/GettingStarted..Some_More|Getting Started With Plasmoids..Some more]] :''A few more starter's tips.''

;[[Development/Tutorials/Plasma/UsingExtenders|How to use extenders in your Plasmoid]]
:''A simple example that shows how to use extenders in a Plasmoid.''

;[http://www.linux-magazine.com/w3/issue/114/036-040_plasma.pdf Creating Plasmoids]
:''May 2010 article from Linux Magazine''

;[http://www.ibm.com/developerworks/linux/library/l-kde-plasmoids/index.html Create Plasmoids using KDevelop]
:''Article explaining the structure of Plasma and how to create a Plasmoid''

;[http://community.kde.org/User:Mxttie#Adding_configuration Adding configuration to your plasmoid]
:''Article explaining how to add a configuration dialog to your plasmoid.''

=== DataEngines ===

;[[Development/Tutorials/Plasma/DataEngines|Writing a DataEngine]]
:''DataEngines provide a standardized interface to various (read only) data sources for visualizations to use. Learn what a DataEngine is and how to write one of your own.''

;[[Development/Tutorials/Plasma/Services|Writing a Service]]
:''Services provide a standardized interface for visualizations to perform "write operations". This can be for example, uploading pasted test to a pastebin service..''

=== PackageStructures ===

;[[Development/Tutorials/Plasma/PackageStructure|Writing a PackageStructure Plugin]]
:''PackageStructure plugins allow custom Packages to be defined, installed, removed and listed as well as provide access their contents at runtime. Packages may contain any kind of data addons, including scripts.''

=== Runners ===

;[[Development/Tutorials/Plasma/AbstractRunner|Creating Runners]]
:''Runners are plugins that provide action-based search functionality in the Plasma workspace "run command" dialog. These plugins can be used by any application that links again libplasma.''

=== Wallpapers ===

;[[Development/Tutorials/Plasma/WallpaperHelloWorld|Wallpaper Tutorial 1]]
:''This tutorial shows you how to make a simple Hello World plasma wallpaper plugin.''

;[[Development/Tutorials/Plasma/WallpaperConfiguration|Wallpaper Tutorial 2]]
:''This tutorial covers how to add configuration options to the wallpaper.''

;[[Development/Tutorials/Plasma/WallpaperDoubleBuffer|Wallpaper Tutorial 3]]
:''This tutorial improves the wallpaper by using the so-called 'double buffer' technique.''

=== Plasma Shells ===

;[[Development/Tutorials/Plasma/ShellDesign|Creating a Plasma Shell]]
:''This tutorial covers the essentials of writing a new Plasma shell from scratch. A must-read for anyone creating a new or modifying an existing Plasma Shell. Existing Plasma shells include Plasma Desktop, Plasma Netbook, Plasma Mobile, Plasma Media Center, Plasma Screensaver, Plasma KPart and Plasma KDM, and all follow the patterns documented here.''

=== Containment actions ===
;[[Development/Tutorials/Plasma/ContainmentAction|Creating a Plasma ContainmentAction]]
:"This tutorial covers the essentials of writing a new Plasma ContainmentAction. You can use a ContainmentAction e.g. for desktop context menus."

== JavaScript ==

Plasma has built-in JavaScript (also known as ECMAScript, and often referred to as QtScript in the context of Qt) scripting support without requiring any external dependencies.

=== Plasmoids ===

;[[Development/Tutorials/Plasma/JavaScript/GettingStarted|Getting Started]]
:''Creating and running your first plasmoid in JavaScript''

;[[Development/Tutorials/Plasma/JavaScript/DataEngine|Getting Data]]
:''How to retrieve data from a data engine''

;[[Development/Tutorials/Plasma/JavaScript/NowPlaying|Now Playing]]
:''Slightly more advanced data engine usage: displaying what's currently playing''

;[[Development/Tutorials/Plasma/JavaScript/SystemMonitor|System Monitor]]
:''How to access systemmonitor data engine''

;[[Development/Tutorials/Plasma/JavaScript/CheatSheet|Cheat Sheet]]
:''A cheat sheet, rather than a tutorial, of things to remember and watch out for when developing JavaScript plasmoids''

;[[Development/Tutorials/Plasma/JavaScript/API|API Reference]]
:''The Simplified JavaScript Plasmoid API. Useful for referencing what is available in the runtime and as a study aid for the tutorials above.''

=== Other Applications Of Javascript ===
;[[KDE_System_Administration/PlasmaDestkopScripting|Scripting Plasma Shells]]
:The KDE Plasma Desktop and Netbook provide means to manage the desktop shell (desktop, panels, widget) via scripts written in JavaScript. This article describes how to take advantage of this feature set as well as documents the full API. This is primarily a system administration tool, but may also be of interest to power users.

;[[Development/Tutorials/Plasma/JavaScript/Animations|Javascript Animations]]
:''How to write Animations using Javascript for use in Plasma applications''

;[[Development/Tutorials/Plasma/ComicPlugin|Creating Comic Plugins]]
:''This guide shows you how to create a comic plugin for the comic plasmoid.''

== Python ==
There are some sample plasmoids written in python https://projects.kde.org/projects/kde/kdeexamples/repository/revisions/master/show/plasma/python

=== Plasmoids ===
;[[Development/Tutorials/Plasma/Python/GettingStarted|Getting Started]]
:''Creating and running your first plasmoid in Python''

;[[Development/Tutorials/Plasma/Python/Using widgets|Using widgets]]
:''Introduction to using Plasma widgets''

;[[Development/Tutorials/Plasma/Python/Using DataEngines|Using DataEngines]]
:''How to use DataEngines from a plasmoid''

=== DataEngines ===

;[[Development/Tutorials/Plasma/Python/Writing DataEngines|Writing DataEngines]]
:''How to write your own Plasma DataEngine''

;[[Development/Tutorials/Plasma/PythonPlasmoid|Writing a Plasmoid in Python]]
:''Writing a simple battery graph in python''

=== Runners ===

;[[Development/Tutorials/Plasma/PythonRunner|Writing a KRunner plugin in Python]]
:''Writing a simple krunner plugin in python''

== Ruby ==

=== Plasmoids ===

;[[Development/Tutorials/Plasma/Ruby/GettingStarted|Getting Started]]
:''Creating and running your first plasmoid in Ruby''

;[[Development/Tutorials/Plasma/Ruby/Using widgets|Using widgets]]
:''Introduction to using Plasma widgets''

;[[Development/Tutorials/Plasma/Ruby/SimplePasteApplet|Writing a simple paste applet]]
:''A tutorial explaining how to set up a plasmoid, create a simple paste applet using widgets and add Plasma features seen elsewhere. Complete with tips for those who have never programmed before.''

;[[Development/Tutorials/Plasma/Ruby/Blinker|Use SVG artwork in the simplest way possible]]
:''Follow a fellow student as he asks around about SVG usage and explains why the code examples work. This is a wiki so feel free to add your own insights until this tutorial can be considered complete.''

=== DataEngines ===

;[[Development/Tutorials/Plasma/Ruby/Writing DataEngines|Writing DataEngines]]
:''How to write your own Plasma DataEngine using Ruby''

== Web Technologies (HTML/JS/CSS) ==
;[[Development/Tutorials/Plasma/Web/GettingStarted|Getting Started]]
:''Creating and running your first plasmoid in HTML''

== Plasma integration for applications ==

;[[Development/Tutorials/Solid_Device_Actions|Creating a Device Notifier action]]
:''When your application is interested in removable hardware''

;[[Development/Tutorials/Plasma/ApplicationShell|Integrate Plasma in Applications]]
:''This tutorial shows you how to make an application dashboard based on Plasma technologies.''

== Packages ==

;[[Development/Tutorials/Plasma/PackageOverview|Plasma Packages]]
:''An overview of what makes up a Plasma Package and what they are and can be used for.''

;[[Development/Tutorials/Plasma/PackageStructure|Writing a PackageStructure Plugin in C++]]
:''PackageStructure plugins allow custom Packages to be defined, installed, removed and listed as well as provide access their contents at runtime. Packages may contain any kind of data addons, including scripts.''

== Themes ==

;[[Development/Tutorials/Plasma/Theme|Creating a Plasma Theme Quickstart]]
:''A quick guide to creating your first Plasma theme''

;[[Development/Tutorials/Plasma/ThemeDetails|The Plasma Theme Structure In Detail]]
:''A comprehensive guide to the contents of a Plasma SVG theme, including configuration options, wallpapers, on-disk layout, names of all standard SVG files and every element in them.''

== Activity Templates ==

;[[KDE_System_Administration/PlasmaDesktopScripting#Activity_templates|Creating a Plasma Activity Template Quickstart]]
:''A quick guide to creating your first Plasma Activity Template''

== Resources ==

* [[Projects/Plasma|Projects: Plasma]]
* [http://api.kde.org/4.x-api/kdelibs-apidocs/plasma/html/index.html Plasma api documentation]
* [http://techbase.kde.org/Projects/Plasma/Eclipse_Integration Plasma Eclipse Integration]
* The [https://mail.kde.org/mailman/listinfo/plasma-devel plasma-devel mailing list] and #plasma on IRC (irc.freenode.org).

Development/Tutorials/Plasma/JavaScript/GettingStarted

2013-02-25T17:04:47Z

Tstaerk: find out where it has been installed

{{TutorialBrowser|

series=JavaScript Plasmoids|

name=Introduction To Writing Plasmoids with JavaScript|

next=[[../DataEngine|Getting Data: How to retrieve data from a DataEngine]]|

reading=[[../API|JavaScript Plasmoid API reference]]
}}

== Abstract ==
In this tutorial we'll cover creating a very simple Plasmoid in JavaScript, otherwise known as [http://doc.trolltech.com/latest/qtscript.html QtScript] or [http://www.ecmascript.org/ ECMAScript], to provide a Plasma widget.

Using JavaScript doesn't require any external dependencies, since it is part of the Qt libraries. As of KDE 4.3, the Plasma JavaScript engine is part of kdebase/runtime, and so can be used in any Plasma-based application, not just the Plasma Desktop.

== What is a widget? ==
In the context of Plasma, a "widget" is a single, self-contained graphical object on the canvas. They can be added and removed individually, configured separately from other widgets, etc. These "mini applications" are sometimes referred to in other widget platforms as "applets", "apps", "gadgets", "karambas", "desklets". We chose the word "widget" for Plasma as it is used by other some other existing systems.

The API of a widget is defined by the host "ScriptEngine", with the exception of native Plasma widgets written in C++ which allows plugins in loadable libraries which use the API of the Plasma library directly. Currently Plasma supports both such "native" widgets written in C++, ones written in various dynamic languages (Plasmoids) as well as:

* SuperKaramba's karambas
* Enlightenment 17 edje content
* Google Gadgets
* MacOS dashboard widgets (though not all)

These are loaded via host AppletScriptEngine plugins that bridge between the widget itself and Plasma's canvas.

== What is a Plasmoid? ==
A Plasmoid is a widget that can be loaded into Plasma that uses the native Plasma API and comes packaged in a single archive file which includes the code, metadata, images, configuration definitions, etc. Plasmoids may be currently written using various scripting languages and APIs. This tutorial covers the Simplified JavaScript API for Plasmoids

== Hello world ==
The first step for any software project is to set up your project's directory on disk. For this tutorial we are going to create a very simple [http://en.wikipedia.org/wiki/Hello_world "Hello world"] plasmoid called "hello-javascript". Create a directory on somewhere called <tt>hello-javascript</tt> which in turn contains a <tt>contents</tt> directory which then contains a <tt>code</tt> directory. This command below will do all this.
<syntaxhighlight lang="bash">
cd
mkdir -p hello-javascript/contents/code
</syntaxhighlight>

The only required part of the structure, in fact, is the <tt>contents</tt> directory - almost everything will go in this directory. But separating your code into a different directory from application data is a good habit to have.

=== Metadata.desktop ===
In the <tt>hello-javascript</tt> directory [[Development/Tutorials/Desktop_File|create a .desktop file]] called <tt>metadata.desktop</tt> with the following content:

<syntaxhighlight lang="ini">
[Desktop Entry]
Name=Hello JavaScript
Comment=An example JavaScript widget
Icon=chronometer

Type=Service
X-KDE-ServiceTypes=Plasma/Applet

X-Plasma-API=javascript
X-Plasma-MainScript=code/main.js
X-Plasma-DefaultSize=200,100

X-KDE-PluginInfo-Author=<Your name here>
X-KDE-PluginInfo-Email=<Your email here>
X-KDE-PluginInfo-Name=hello-javascript
X-KDE-PluginInfo-Version=1.0
X-KDE-PluginInfo-Website=http://plasma.kde.org/
X-KDE-PluginInfo-Category=Examples
X-KDE-PluginInfo-Depends=
X-KDE-PluginInfo-License=GPL
X-KDE-PluginInfo-EnabledByDefault=true
</syntaxhighlight>

This <tt>metadata.desktop</tt> file list important information needed by Plasma to load the widget, and also information about what the widget is and who created it.

<tt>Name</tt> gives the name of widget as seen by the user when they go to the Add Widget dialog on the desktop. There can be additional name entries for different languages. For example, you could add a Dutch translation by inserting the line <tt>Name[nl]=Hallo JavaScript</tt>.

<tt>Comment</tt> gives a more detailed description of the widget. This is also displayed in the Add Widget dialog, and can be translated in the same way as <tt>Name</tt>.

<tt>Icon</tt> gives the name of the icon to associate with this plasmoid. The icon is shown in the Add Widget dialog. It must be the name of an icon that is either distributed with KDE (such as <tt>chronometer</tt>) or provided by your plasmoid. If you want to provide the icon, you can use <tt>Icon=icon.png</tt>.

The <tt>Type</tt>, <tt>X-KDE-ServiceTypes</tt>, <tt>X-Plasma-API</tt> and <tt>X-Plasma-MainScript</tt> fields are required for Plasma to find your plasmoid and know what to do with it. Note that <tt>X-Plasma-MainScript</tt> is a path relative the <tt>contents</tt> directory.

<tt>X-Plasma-DefaultSize</tt> specifies the default size for widget, as <tt>width,height</tt>. While the units aren't technically pixels, they have the same value as pixels providing you don't do anything like zoom in or out on your desktop.

<tt>X-KDE-PluginInfo-Category</tt> gives a category for the widget. This is used in the Add Widgets dialog to group and filter widgets. The value must be one of the category names listed at [[Projects/Plasma/PIG]].

<tt>X-KDE-PluginInfo-Name</tt> is the internal name of the plasmoid (you can think of this as the name of the plasmoid, as opposed to the name of the widget which is given by <tt>Name</tt>). This is the name you will use as an argument to <tt>plasmoidviewer</tt> or <tt>plasmapkg</tt> when you need to provide a plasmoid name rather than a path. It doesn't have to be the same name as the directory containing <tt>metadata.desktop</tt>.

<tt>X-KDE-PluginInfo-Author</tt>, <tt>X-KDE-PluginInfo-Email</tt>, <tt>X-KDE-PluginInfo-Version</tt>, <tt>X-KDE-PluginInfo-Website</tt> and <tt>X-KDE-PluginInfo-License</tt> are informational, and are displayed in the About dialog for the plasmoid (which can be viewed by clicking the information icon next to the corresponding widget in the Add Widgets dialog of plasma).

<tt>X-KDE-PluginInfo-EnabledByDefault</tt> and <tt>X-KDE-PluginInfo-Depends</tt> rarely need to be changed from the values given here.

=== Main script ===
The name of the main script file is given by <tt>X-Plasma-MainScript</tt> in metadata.desktop, and is relative to the <tt>contents</tt> directory. In our case, we will need to create the file <tt>hello-javascript/contents/code/main.js</tt>. Put the following code in it:

<syntaxhighlight lang="javascript">
layout = new LinearLayout(plasmoid);

label = new Label();
layout.addItem(label);

label.text = 'Hello JavaScript!';
</syntaxhighlight>

<strong>plasmoid</strong> is a global variable that represents your widget. It has some useful methods that we'll come to in later tutorials.

First, we create a layout, because plasmoids don't have a layout by default. This just makes sure that the label is the correct size and in the correct place. Passing <tt>plasmoid</tt> to the <tt>LinearLayout</tt> attaches the layout to the widget.

Next we add a label to the layout, and finally we set the label text.

=== Testing (KDE 4.3+) ===
If you have KDE 4.3 or later, you can test your plasmoid without installing it by entering the <tt>hello-javascript</tt> directory and running <tt>plasmoidviewer</tt>. Alternatively, call
<syntaxhighlight lang="bash">
plasmoidviewer ~/hello-javascript
</syntaxhighlight>

This is very convenient for development as you can edit the Plasmoid and test the changes immediately without re-installing the plasmoid over and over again.

=== Installing ===
You can install the plasmoid by running the following command from within the <tt>hello-javascript</tt> directory:
<syntaxhighlight lang="bash">
plasmapkg -i .
</syntaxhighlight>

The final argument to <tt>plasmapkg</tt> is the path to the directory containing <tt>metadata.desktop</tt> and the <tt>contents</tt> directory.

You can now add your widget to the desktop using the Add Widgets dialog, or view it by running
<syntaxhighlight lang="bash">
plasmoidviewer hello-javascript
</syntaxhighlight>

If you want to see where your plasmoid has actually been installed you can find out like this:
# plasmapkg -i .
plasmapkg(6482)/libplasma Plasma::Package::installPackage: "/root/.kde4/share/apps/plasma/plasmoids//hello-javascript" already exists
Installation of /root/hello-javascript failed.
In this case it has been installed to /root/.kde4/share/apps/plasma/plasmoids//hello-javascript.

=== Packaging ===
If you want to share your plasmoid, you'll have to package it. Run the following from within the <tt>hello-javascript</tt> directory:
<syntaxhighlight lang="bash">
zip -r ../hello-javascript.zip . &&
mv ../hello-javascript.zip ../hello-javascript.plasmoid
</syntaxhighlight>

You now have a plasmoid package you can share with the world. To install it, either use the "Install new widgets" functionality in the Add Widgets dialog, or go to the directory containing <tt>hello-javascript.plasmoid</tt> and run
<syntaxhighlight lang="bash">
plasmapkg -i hello-javascript.plasmoid
</syntaxhighlight>

To uninstall the plasmoid, use <tt>plasmapkg</tt> again with its -r option:
<syntaxhighlight lang="bash">
plasmapkg -r hello-javascript
</syntaxhighlight>

Note that while the argument to <tt>plasmapkg -i</tt> is a file or directory, you need to pass the plasmoid name (given by <tt>X-KDE-PluginInfo-Name</tt> in <tt>metadata.desktop</tt>) to <tt>plasmapkg -r</tt>.

== QtScript ==
The Simplified JavaScript API is powered by Qt's QtScript system which provides access to a full featured ECMA Script interpreter. If it works in ECMA Script, it will work in a Simplified JavaScript Plasmoid.

{{note|QtScript uses the high performance ECMA Script interpreter from WebKit and shares this code with QtWebKit.

However, QtScript does not include things such as a DOM API those familiar with JavaScript from a web browser context may expect. It is ''just'' ECMA Script with Qt integration.}}

On top of the ECMA Script language, QtScript provides Qt integration features. Probably the most useful one in the context of writing Plasmoids is the use of signals and slots which is Qt's callback mechanism. Signals may be emitted in QtScript by calling the signal method in question, a signal can be connected to a slot by using the connect() method (and disconnected with disconnect()) and any function defined in the Plasmoid may be used as a slot. For example:

<syntaxhighlight lang="javascript">
function onClick()
{
print("We got clicked!")
}

function onFirstClick()
{
print("First click!")
button.clicked.disconnect(onFirstClick)
}

button = new PushButton
button.clicked.connect(onClick)
button.clicked.connect(onFirstClick)
button.clicked()
</syntaxhighlight>

This will print out:

<syntaxhighlight lang="text">
We got clicked!
First click!
</syntaxhighlight>

on the console when the Plasmoid starts, and the "We got clicked!" again whenever the button is clicked by the user.

Development/Tutorials/Plasma/JavaScript/GettingStarted

2013-02-25T16:10:05Z

Tstaerk: actually it's not needed to use a text editor

{{TutorialBrowser|

series=JavaScript Plasmoids|

name=Introduction To Writing Plasmoids with JavaScript|

next=[[../DataEngine|Getting Data: How to retrieve data from a DataEngine]]|

reading=[[../API|JavaScript Plasmoid API reference]]
}}

== Abstract ==
In this tutorial we'll cover creating a very simple Plasmoid in JavaScript, otherwise known as [http://doc.trolltech.com/latest/qtscript.html QtScript] or [http://www.ecmascript.org/ ECMAScript], to provide a Plasma widget.

Using JavaScript doesn't require any external dependencies, since it is part of the Qt libraries. As of KDE 4.3, the Plasma JavaScript engine is part of kdebase/runtime, and so can be used in any Plasma-based application, not just the Plasma Desktop.

== What is a widget? ==
In the context of Plasma, a "widget" is a single, self-contained graphical object on the canvas. They can be added and removed individually, configured separately from other widgets, etc. These "mini applications" are sometimes referred to in other widget platforms as "applets", "apps", "gadgets", "karambas", "desklets". We chose the word "widget" for Plasma as it is used by other some other existing systems.

The API of a widget is defined by the host "ScriptEngine", with the exception of native Plasma widgets written in C++ which allows plugins in loadable libraries which use the API of the Plasma library directly. Currently Plasma supports both such "native" widgets written in C++, ones written in various dynamic languages (Plasmoids) as well as:

* SuperKaramba's karambas
* Enlightenment 17 edje content
* Google Gadgets
* MacOS dashboard widgets (though not all)

These are loaded via host AppletScriptEngine plugins that bridge between the widget itself and Plasma's canvas.

== What is a Plasmoid? ==
A Plasmoid is a widget that can be loaded into Plasma that uses the native Plasma API and comes packaged in a single archive file which includes the code, metadata, images, configuration definitions, etc. Plasmoids may be currently written using various scripting languages and APIs. This tutorial covers the Simplified JavaScript API for Plasmoids

== Hello world ==
The first step for any software project is to set up your project's directory on disk. For this tutorial we are going to create a very simple [http://en.wikipedia.org/wiki/Hello_world "Hello world"] plasmoid called "hello-javascript". Create a directory on somewhere called <tt>hello-javascript</tt> which in turn contains a <tt>contents</tt> directory which then contains a <tt>code</tt> directory. This command below will do all this.
<syntaxhighlight lang="bash">
cd
mkdir -p hello-javascript/contents/code
</syntaxhighlight>

The only required part of the structure, in fact, is the <tt>contents</tt> directory - almost everything will go in this directory. But separating your code into a different directory from application data is a good habit to have.

=== Metadata.desktop ===
In the <tt>hello-javascript</tt> directory [[Development/Tutorials/Desktop_File|create a .desktop file]] called <tt>metadata.desktop</tt> with the following content:

<syntaxhighlight lang="ini">
[Desktop Entry]
Name=Hello JavaScript
Comment=An example JavaScript widget
Icon=chronometer

Type=Service
X-KDE-ServiceTypes=Plasma/Applet

X-Plasma-API=javascript
X-Plasma-MainScript=code/main.js
X-Plasma-DefaultSize=200,100

X-KDE-PluginInfo-Author=<Your name here>
X-KDE-PluginInfo-Email=<Your email here>
X-KDE-PluginInfo-Name=hello-javascript
X-KDE-PluginInfo-Version=1.0
X-KDE-PluginInfo-Website=http://plasma.kde.org/
X-KDE-PluginInfo-Category=Examples
X-KDE-PluginInfo-Depends=
X-KDE-PluginInfo-License=GPL
X-KDE-PluginInfo-EnabledByDefault=true
</syntaxhighlight>

This <tt>metadata.desktop</tt> file list important information needed by Plasma to load the widget, and also information about what the widget is and who created it.

<tt>Name</tt> gives the name of widget as seen by the user when they go to the Add Widget dialog on the desktop. There can be additional name entries for different languages. For example, you could add a Dutch translation by inserting the line <tt>Name[nl]=Hallo JavaScript</tt>.

<tt>Comment</tt> gives a more detailed description of the widget. This is also displayed in the Add Widget dialog, and can be translated in the same way as <tt>Name</tt>.

<tt>Icon</tt> gives the name of the icon to associate with this plasmoid. The icon is shown in the Add Widget dialog. It must be the name of an icon that is either distributed with KDE (such as <tt>chronometer</tt>) or provided by your plasmoid. If you want to provide the icon, you can use <tt>Icon=icon.png</tt>.

The <tt>Type</tt>, <tt>X-KDE-ServiceTypes</tt>, <tt>X-Plasma-API</tt> and <tt>X-Plasma-MainScript</tt> fields are required for Plasma to find your plasmoid and know what to do with it. Note that <tt>X-Plasma-MainScript</tt> is a path relative the <tt>contents</tt> directory.

<tt>X-Plasma-DefaultSize</tt> specifies the default size for widget, as <tt>width,height</tt>. While the units aren't technically pixels, they have the same value as pixels providing you don't do anything like zoom in or out on your desktop.

<tt>X-KDE-PluginInfo-Category</tt> gives a category for the widget. This is used in the Add Widgets dialog to group and filter widgets. The value must be one of the category names listed at [[Projects/Plasma/PIG]].

<tt>X-KDE-PluginInfo-Name</tt> is the internal name of the plasmoid (you can think of this as the name of the plasmoid, as opposed to the name of the widget which is given by <tt>Name</tt>). This is the name you will use as an argument to <tt>plasmoidviewer</tt> or <tt>plasmapkg</tt> when you need to provide a plasmoid name rather than a path. It doesn't have to be the same name as the directory containing <tt>metadata.desktop</tt>.

<tt>X-KDE-PluginInfo-Author</tt>, <tt>X-KDE-PluginInfo-Email</tt>, <tt>X-KDE-PluginInfo-Version</tt>, <tt>X-KDE-PluginInfo-Website</tt> and <tt>X-KDE-PluginInfo-License</tt> are informational, and are displayed in the About dialog for the plasmoid (which can be viewed by clicking the information icon next to the corresponding widget in the Add Widgets dialog of plasma).

<tt>X-KDE-PluginInfo-EnabledByDefault</tt> and <tt>X-KDE-PluginInfo-Depends</tt> rarely need to be changed from the values given here.

=== Main script ===
The name of the main script file is given by <tt>X-Plasma-MainScript</tt> in metadata.desktop, and is relative to the <tt>contents</tt> directory. In our case, we will need to create the file <tt>hello-javascript/contents/code/main.js</tt>. Put the following code in it:

<syntaxhighlight lang="javascript">
layout = new LinearLayout(plasmoid);

label = new Label();
layout.addItem(label);

label.text = 'Hello JavaScript!';
</syntaxhighlight>

<strong>plasmoid</strong> is a global variable that represents your widget. It has some useful methods that we'll come to in later tutorials.

First, we create a layout, because plasmoids don't have a layout by default. This just makes sure that the label is the correct size and in the correct place. Passing <tt>plasmoid</tt> to the <tt>LinearLayout</tt> attaches the layout to the widget.

Next we add a label to the layout, and finally we set the label text.

=== Testing (KDE 4.3+) ===
If you have KDE 4.3 or later, you can test your plasmoid without installing it by entering the <tt>hello-javascript</tt> directory and running <tt>plasmoidviewer</tt>. Alternatively, call
<syntaxhighlight lang="bash">
plasmoidviewer ~/hello-javascript
</syntaxhighlight>

This is very convenient for development as you can edit the Plasmoid and test the changes immediately without re-installing the plasmoid over and over again.

=== Installing ===
You can install the plasmoid by running the following command from within the <tt>hello-javascript</tt> directory:
<syntaxhighlight lang="bash">
plasmapkg -i .
</syntaxhighlight>

The final argument to <tt>plasmapkg</tt> is the path to the directory containing <tt>metadata.desktop</tt> and the <tt>contents</tt> directory.

You can now add your widget to the desktop using the Add Widgets dialog, or view it by running
<syntaxhighlight lang="bash">
plasmoidviewer hello-javascript
</syntaxhighlight>

=== Packaging ===
If you want to share your plasmoid, you'll have to package it. Run the following from within the <tt>hello-javascript</tt> directory:
<syntaxhighlight lang="bash">
zip -r ../hello-javascript.zip . &&
mv ../hello-javascript.zip ../hello-javascript.plasmoid
</syntaxhighlight>

You now have a plasmoid package you can share with the world. To install it, either use the "Install new widgets" functionality in the Add Widgets dialog, or go to the directory containing <tt>hello-javascript.plasmoid</tt> and run
<syntaxhighlight lang="bash">
plasmapkg -i hello-javascript.plasmoid
</syntaxhighlight>

To uninstall the plasmoid, use <tt>plasmapkg</tt> again with its -r option:
<syntaxhighlight lang="bash">
plasmapkg -r hello-javascript
</syntaxhighlight>

Note that while the argument to <tt>plasmapkg -i</tt> is a file or directory, you need to pass the plasmoid name (given by <tt>X-KDE-PluginInfo-Name</tt> in <tt>metadata.desktop</tt>) to <tt>plasmapkg -r</tt>.

== QtScript ==
The Simplified JavaScript API is powered by Qt's QtScript system which provides access to a full featured ECMA Script interpreter. If it works in ECMA Script, it will work in a Simplified JavaScript Plasmoid.

{{note|QtScript uses the high performance ECMA Script interpreter from WebKit and shares this code with QtWebKit.

However, QtScript does not include things such as a DOM API those familiar with JavaScript from a web browser context may expect. It is ''just'' ECMA Script with Qt integration.}}

On top of the ECMA Script language, QtScript provides Qt integration features. Probably the most useful one in the context of writing Plasmoids is the use of signals and slots which is Qt's callback mechanism. Signals may be emitted in QtScript by calling the signal method in question, a signal can be connected to a slot by using the connect() method (and disconnected with disconnect()) and any function defined in the Plasmoid may be used as a slot. For example:

<syntaxhighlight lang="javascript">
function onClick()
{
print("We got clicked!")
}

function onFirstClick()
{
print("First click!")
button.clicked.disconnect(onFirstClick)
}

button = new PushButton
button.clicked.connect(onClick)
button.clicked.connect(onFirstClick)
button.clicked()
</syntaxhighlight>

This will print out:

<syntaxhighlight lang="text">
We got clicked!
First click!
</syntaxhighlight>

on the console when the Plasmoid starts, and the "We got clicked!" again whenever the button is clicked by the user.

Development/Tutorials/Plasma/JavaScript/GettingStarted

2013-02-25T16:05:41Z

Tstaerk: the "hello world" program explains how to write, execute and install a program

{{TutorialBrowser|

series=JavaScript Plasmoids|

name=Introduction To Writing Plasmoids with JavaScript|

next=[[../DataEngine|Getting Data: How to retrieve data from a DataEngine]]|

reading=[[../API|JavaScript Plasmoid API reference]]
}}

== Abstract ==
In this tutorial we'll cover creating a very simple Plasmoid in JavaScript, otherwise known as [http://doc.trolltech.com/latest/qtscript.html QtScript] or [http://www.ecmascript.org/ ECMAScript], to provide a Plasma widget.

Using JavaScript doesn't require any external dependencies, since it is part of the Qt libraries. As of KDE 4.3, the Plasma JavaScript engine is part of kdebase/runtime, and so can be used in any Plasma-based application, not just the Plasma Desktop.

== What is a widget? ==
In the context of Plasma, a "widget" is a single, self-contained graphical object on the canvas. They can be added and removed individually, configured separately from other widgets, etc. These "mini applications" are sometimes referred to in other widget platforms as "applets", "apps", "gadgets", "karambas", "desklets". We chose the word "widget" for Plasma as it is used by other some other existing systems.

The API of a widget is defined by the host "ScriptEngine", with the exception of native Plasma widgets written in C++ which allows plugins in loadable libraries which use the API of the Plasma library directly. Currently Plasma supports both such "native" widgets written in C++, ones written in various dynamic languages (Plasmoids) as well as:

* SuperKaramba's karambas
* Enlightenment 17 edje content
* Google Gadgets
* MacOS dashboard widgets (though not all)

These are loaded via host AppletScriptEngine plugins that bridge between the widget itself and Plasma's canvas.

== What is a Plasmoid? ==
A Plasmoid is a widget that can be loaded into Plasma that uses the native Plasma API and comes packaged in a single archive file which includes the code, metadata, images, configuration definitions, etc. Plasmoids may be currently written using various scripting languages and APIs. This tutorial covers the Simplified JavaScript API for Plasmoids

== Hello world ==
The first step for any software project is to set up your project's directory on disk. For this tutorial we are going to create a very simple [http://en.wikipedia.org/wiki/Hello_world "Hello world"] plasmoid called "hello-javascript". Create a directory on somewhere called <tt>hello-javascript</tt> which in turn contains a <tt>contents</tt> directory which then contains a <tt>code</tt> directory. This command below will do all this.
<syntaxhighlight lang="bash">
cd
mkdir -p hello-javascript/contents/code
</syntaxhighlight>

The only required part of the structure, in fact, is the <tt>contents</tt> directory - almost everything will go in this directory. But separating your code into a different directory from application data is a good habit to have.

=== Metadata.desktop ===
In the <tt>hello-javascript</tt> directory create a file called <tt>metadata.desktop</tt> and open it in your text editor. Copy the following code into <tt>metadata.desktop</tt>.

<syntaxhighlight lang="ini">
[Desktop Entry]
Name=Hello JavaScript
Comment=An example JavaScript widget
Icon=chronometer

Type=Service
X-KDE-ServiceTypes=Plasma/Applet

X-Plasma-API=javascript
X-Plasma-MainScript=code/main.js
X-Plasma-DefaultSize=200,100

X-KDE-PluginInfo-Author=<Your name here>
X-KDE-PluginInfo-Email=<Your email here>
X-KDE-PluginInfo-Name=hello-javascript
X-KDE-PluginInfo-Version=1.0
X-KDE-PluginInfo-Website=http://plasma.kde.org/
X-KDE-PluginInfo-Category=Examples
X-KDE-PluginInfo-Depends=
X-KDE-PluginInfo-License=GPL
X-KDE-PluginInfo-EnabledByDefault=true
</syntaxhighlight>

This <tt>metadata.desktop</tt> file list important information needed by Plasma to load the widget, and also information about what the widget is and who created it.

<tt>Name</tt> gives the name of widget as seen by the user when they go to the Add Widget dialog on the desktop. There can be additional name entries for different languages. For example, you could add a Dutch translation by inserting the line <tt>Name[nl]=Hallo JavaScript</tt>.

<tt>Comment</tt> gives a more detailed description of the widget. This is also displayed in the Add Widget dialog, and can be translated in the same way as <tt>Name</tt>.

<tt>Icon</tt> gives the name of the icon to associate with this plasmoid. The icon is shown in the Add Widget dialog. It must be the name of an icon that is either distributed with KDE (such as <tt>chronometer</tt>) or provided by your plasmoid. If you want to provide the icon, you can use <tt>Icon=icon.png</tt>.

The <tt>Type</tt>, <tt>X-KDE-ServiceTypes</tt>, <tt>X-Plasma-API</tt> and <tt>X-Plasma-MainScript</tt> fields are required for Plasma to find your plasmoid and know what to do with it. Note that <tt>X-Plasma-MainScript</tt> is a path relative the <tt>contents</tt> directory.

<tt>X-Plasma-DefaultSize</tt> specifies the default size for widget, as <tt>width,height</tt>. While the units aren't technically pixels, they have the same value as pixels providing you don't do anything like zoom in or out on your desktop.

<tt>X-KDE-PluginInfo-Category</tt> gives a category for the widget. This is used in the Add Widgets dialog to group and filter widgets. The value must be one of the category names listed at [[Projects/Plasma/PIG]].

<tt>X-KDE-PluginInfo-Name</tt> is the internal name of the plasmoid (you can think of this as the name of the plasmoid, as opposed to the name of the widget which is given by <tt>Name</tt>). This is the name you will use as an argument to <tt>plasmoidviewer</tt> or <tt>plasmapkg</tt> when you need to provide a plasmoid name rather than a path. It doesn't have to be the same name as the directory containing <tt>metadata.desktop</tt>.

<tt>X-KDE-PluginInfo-Author</tt>, <tt>X-KDE-PluginInfo-Email</tt>, <tt>X-KDE-PluginInfo-Version</tt>, <tt>X-KDE-PluginInfo-Website</tt> and <tt>X-KDE-PluginInfo-License</tt> are informational, and are displayed in the About dialog for the plasmoid (which can be viewed by clicking the information icon next to the corresponding widget in the Add Widgets dialog of plasma).

<tt>X-KDE-PluginInfo-EnabledByDefault</tt> and <tt>X-KDE-PluginInfo-Depends</tt> rarely need to be changed from the values given here.

=== Main script ===
The name of the main script file is given by <tt>X-Plasma-MainScript</tt> in metadata.desktop, and is relative to the <tt>contents</tt> directory. In our case, we will need to create the file <tt>hello-javascript/contents/code/main.js</tt>. Put the following code in it:

<syntaxhighlight lang="javascript">
layout = new LinearLayout(plasmoid);

label = new Label();
layout.addItem(label);

label.text = 'Hello JavaScript!';
</syntaxhighlight>

<strong>plasmoid</strong> is a global variable that represents your widget. It has some useful methods that we'll come to in later tutorials.

First, we create a layout, because plasmoids don't have a layout by default. This just makes sure that the label is the correct size and in the correct place. Passing <tt>plasmoid</tt> to the <tt>LinearLayout</tt> attaches the layout to the widget.

Next we add a label to the layout, and finally we set the label text.

=== Testing (KDE 4.3+) ===
If you have KDE 4.3 or later, you can test your plasmoid without installing it by entering the <tt>hello-javascript</tt> directory and running <tt>plasmoidviewer</tt>. Alternatively, call
<syntaxhighlight lang="bash">
plasmoidviewer ~/hello-javascript
</syntaxhighlight>

This is very convenient for development as you can edit the Plasmoid and test the changes immediately without re-installing the plasmoid over and over again.

=== Installing ===
You can install the plasmoid by running the following command from within the <tt>hello-javascript</tt> directory:
<syntaxhighlight lang="bash">
plasmapkg -i .
</syntaxhighlight>

The final argument to <tt>plasmapkg</tt> is the path to the directory containing <tt>metadata.desktop</tt> and the <tt>contents</tt> directory.

You can now add your widget to the desktop using the Add Widgets dialog, or view it by running
<syntaxhighlight lang="bash">
plasmoidviewer hello-javascript
</syntaxhighlight>

=== Packaging ===
If you want to share your plasmoid, you'll have to package it. Run the following from within the <tt>hello-javascript</tt> directory:
<syntaxhighlight lang="bash">
zip -r ../hello-javascript.zip . &&
mv ../hello-javascript.zip ../hello-javascript.plasmoid
</syntaxhighlight>

You now have a plasmoid package you can share with the world. To install it, either use the "Install new widgets" functionality in the Add Widgets dialog, or go to the directory containing <tt>hello-javascript.plasmoid</tt> and run
<syntaxhighlight lang="bash">
plasmapkg -i hello-javascript.plasmoid
</syntaxhighlight>

To uninstall the plasmoid, use <tt>plasmapkg</tt> again with its -r option:
<syntaxhighlight lang="bash">
plasmapkg -r hello-javascript
</syntaxhighlight>

Note that while the argument to <tt>plasmapkg -i</tt> is a file or directory, you need to pass the plasmoid name (given by <tt>X-KDE-PluginInfo-Name</tt> in <tt>metadata.desktop</tt>) to <tt>plasmapkg -r</tt>.

== QtScript ==
The Simplified JavaScript API is powered by Qt's QtScript system which provides access to a full featured ECMA Script interpreter. If it works in ECMA Script, it will work in a Simplified JavaScript Plasmoid.

{{note|QtScript uses the high performance ECMA Script interpreter from WebKit and shares this code with QtWebKit.

However, QtScript does not include things such as a DOM API those familiar with JavaScript from a web browser context may expect. It is ''just'' ECMA Script with Qt integration.}}

On top of the ECMA Script language, QtScript provides Qt integration features. Probably the most useful one in the context of writing Plasmoids is the use of signals and slots which is Qt's callback mechanism. Signals may be emitted in QtScript by calling the signal method in question, a signal can be connected to a slot by using the connect() method (and disconnected with disconnect()) and any function defined in the Plasmoid may be used as a slot. For example:

<syntaxhighlight lang="javascript">
function onClick()
{
print("We got clicked!")
}

function onFirstClick()
{
print("First click!")
button.clicked.disconnect(onFirstClick)
}

button = new PushButton
button.clicked.connect(onClick)
button.clicked.connect(onFirstClick)
button.clicked()
</syntaxhighlight>

This will print out:

<syntaxhighlight lang="text">
We got clicked!
First click!
</syntaxhighlight>

on the console when the Plasmoid starts, and the "We got clicked!" again whenever the button is clicked by the user.

Development/Tutorials/Plasma/JavaScript/GettingStarted

2013-02-25T16:03:28Z

Tstaerk: hello world

{{TutorialBrowser|

series=JavaScript Plasmoids|

name=Introduction To Writing Plasmoids with JavaScript|

next=[[../DataEngine|Getting Data: How to retrieve data from a DataEngine]]|

reading=[[../API|JavaScript Plasmoid API reference]]
}}

== Abstract ==

In this tutorial we'll cover creating a very simple Plasmoid in JavaScript, otherwise known as [http://doc.trolltech.com/latest/qtscript.html QtScript] or [http://www.ecmascript.org/ ECMAScript], to provide a Plasma widget.

Using JavaScript doesn't require any external dependencies, since it is part of the Qt libraries. As of KDE 4.3, the Plasma JavaScript engine is part of kdebase/runtime, and so can be used in any Plasma-based application, not just the Plasma Desktop.

== What is a widget? ==
In the context of Plasma, a "widget" is a single, self-contained graphical object on the canvas. They can be added and removed individually, configured separately from other widgets, etc. These "mini applications" are sometimes referred to in other widget platforms as "applets", "apps", "gadgets", "karambas", "desklets". We chose the word "widget" for Plasma as it is used by other some other existing systems.

The API of a widget is defined by the host "ScriptEngine", with the exception of native Plasma widgets written in C++ which allows plugins in loadable libraries which use the API of the Plasma library directly. Currently Plasma supports both such "native" widgets written in C++, ones written in various dynamic languages (Plasmoids) as well as:

* SuperKaramba's karambas
* Enlightenment 17 edje content
* Google Gadgets
* MacOS dashboard widgets (though not all)

These are loaded via host AppletScriptEngine plugins that bridge between the widget itself and Plasma's canvas.

== What is a Plasmoid? ==

A Plasmoid is a widget that can be loaded into Plasma that uses the native Plasma API and comes packaged in a single archive file which includes the code, metadata, images, configuration definitions, etc. Plasmoids may be currently written using various scripting languages and APIs. This tutorial covers the Simplified JavaScript API for Plasmoids

== Hello world ==
The first step for any software project is to set up your project's directory on disk. For this tutorial we are going to create a very simple [http://en.wikipedia.org/wiki/Hello_world "Hello world"] plasmoid called "hello-javascript". Create a directory on somewhere called <tt>hello-javascript</tt> which in turn contains a <tt>contents</tt> directory which then contains a <tt>code</tt> directory. This command below will do all this.
<syntaxhighlight lang="bash">
cd
mkdir -p hello-javascript/contents/code
</syntaxhighlight>

The only required part of the structure, in fact, is the <tt>contents</tt> directory - almost everything will go in this directory. But separating your code into a different directory from application data is a good habit to have.

== Metadata.desktop ==

In the <tt>hello-javascript</tt> directory create a file called <tt>metadata.desktop</tt> and open it in your text editor. Copy the following code into <tt>metadata.desktop</tt>.

<syntaxhighlight lang="ini">
[Desktop Entry]
Name=Hello JavaScript
Comment=An example JavaScript widget
Icon=chronometer

Type=Service
X-KDE-ServiceTypes=Plasma/Applet

X-Plasma-API=javascript
X-Plasma-MainScript=code/main.js
X-Plasma-DefaultSize=200,100

X-KDE-PluginInfo-Author=<Your name here>
X-KDE-PluginInfo-Email=<Your email here>
X-KDE-PluginInfo-Name=hello-javascript
X-KDE-PluginInfo-Version=1.0
X-KDE-PluginInfo-Website=http://plasma.kde.org/
X-KDE-PluginInfo-Category=Examples
X-KDE-PluginInfo-Depends=
X-KDE-PluginInfo-License=GPL
X-KDE-PluginInfo-EnabledByDefault=true
</syntaxhighlight>

This <tt>metadata.desktop</tt> file list important information needed by Plasma to load the widget, and also information about what the widget is and who created it.

<tt>Name</tt> gives the name of widget as seen by the user when they go to the Add Widget dialog on the desktop. There can be additional name entries for different languages. For example, you could add a Dutch translation by inserting the line <tt>Name[nl]=Hallo JavaScript</tt>.

<tt>Comment</tt> gives a more detailed description of the widget. This is also displayed in the Add Widget dialog, and can be translated in the same way as <tt>Name</tt>.

<tt>Icon</tt> gives the name of the icon to associate with this plasmoid. The icon is shown in the Add Widget dialog. It must be the name of an icon that is either distributed with KDE (such as <tt>chronometer</tt>) or provided by your plasmoid. If you want to provide the icon, you can use <tt>Icon=icon.png</tt>.

The <tt>Type</tt>, <tt>X-KDE-ServiceTypes</tt>, <tt>X-Plasma-API</tt> and <tt>X-Plasma-MainScript</tt> fields are required for Plasma to find your plasmoid and know what to do with it. Note that <tt>X-Plasma-MainScript</tt> is a path relative the <tt>contents</tt> directory.

<tt>X-Plasma-DefaultSize</tt> specifies the default size for widget, as <tt>width,height</tt>. While the units aren't technically pixels, they have the same value as pixels providing you don't do anything like zoom in or out on your desktop.

<tt>X-KDE-PluginInfo-Category</tt> gives a category for the widget. This is used in the Add Widgets dialog to group and filter widgets. The value must be one of the category names listed at [[Projects/Plasma/PIG]].

<tt>X-KDE-PluginInfo-Name</tt> is the internal name of the plasmoid (you can think of this as the name of the plasmoid, as opposed to the name of the widget which is given by <tt>Name</tt>). This is the name you will use as an argument to <tt>plasmoidviewer</tt> or <tt>plasmapkg</tt> when you need to provide a plasmoid name rather than a path. It doesn't have to be the same name as the directory containing <tt>metadata.desktop</tt>.

<tt>X-KDE-PluginInfo-Author</tt>, <tt>X-KDE-PluginInfo-Email</tt>, <tt>X-KDE-PluginInfo-Version</tt>, <tt>X-KDE-PluginInfo-Website</tt> and <tt>X-KDE-PluginInfo-License</tt> are informational, and are displayed in the About dialog for the plasmoid (which can be viewed by clicking the information icon next to the corresponding widget in the Add Widgets dialog of plasma).

<tt>X-KDE-PluginInfo-EnabledByDefault</tt> and <tt>X-KDE-PluginInfo-Depends</tt> rarely need to be changed from the values given here.

== Main script ==

The name of the main script file is given by <tt>X-Plasma-MainScript</tt> in metadata.desktop, and is relative to the <tt>contents</tt> directory. In our case, we will need to create the file <tt>hello-javascript/contents/code/main.js</tt>. Put the following code in it:

<syntaxhighlight lang="javascript">
layout = new LinearLayout(plasmoid);

label = new Label();
layout.addItem(label);

label.text = 'Hello JavaScript!';
</syntaxhighlight>

<strong>plasmoid</strong> is a global variable that represents your widget. It has some useful methods that we'll come to in later tutorials.

First, we create a layout, because plasmoids don't have a layout by default. This just makes sure that the label is the correct size and in the correct place. Passing <tt>plasmoid</tt> to the <tt>LinearLayout</tt> attaches the layout to the widget.

Next we add a label to the layout, and finally we set the label text.

== Testing (KDE 4.3+) ==

If you have KDE 4.3 or later, you can test your plasmoid without installing it by entering the <tt>hello-javascript</tt> directory and running <tt>plasmoidviewer</tt>. Alternatively, call
<syntaxhighlight lang="bash">
plasmoidviewer ~/hello-javascript
</syntaxhighlight>

This is very convenient for development as you can edit the Plasmoid and test the changes immediately without re-installing the plasmoid over and over again.

== Installing ==

You can install the plasmoid by running the following command from within the <tt>hello-javascript</tt> directory:
<syntaxhighlight lang="bash">
plasmapkg -i .
</syntaxhighlight>

The final argument to <tt>plasmapkg</tt> is the path to the directory containing <tt>metadata.desktop</tt> and the <tt>contents</tt> directory.

You can now add your widget to the desktop using the Add Widgets dialog, or view it by running
<syntaxhighlight lang="bash">
plasmoidviewer hello-javascript
</syntaxhighlight>

== Packaging ==

If you want to share your plasmoid, you'll have to package it. Run the following from within the <tt>hello-javascript</tt> directory:
<syntaxhighlight lang="bash">
zip -r ../hello-javascript.zip . &&
mv ../hello-javascript.zip ../hello-javascript.plasmoid
</syntaxhighlight>

You now have a plasmoid package you can share with the world. To install it, either use the "Install new widgets" functionality in the Add Widgets dialog, or go to the directory containing <tt>hello-javascript.plasmoid</tt> and run
<syntaxhighlight lang="bash">
plasmapkg -i hello-javascript.plasmoid
</syntaxhighlight>

To uninstall the plasmoid, use <tt>plasmapkg</tt> again with its -r option:
<syntaxhighlight lang="bash">
plasmapkg -r hello-javascript
</syntaxhighlight>

Note that while the argument to <tt>plasmapkg -i</tt> is a file or directory, you need to pass the plasmoid name (given by <tt>X-KDE-PluginInfo-Name</tt> in <tt>metadata.desktop</tt>) to <tt>plasmapkg -r</tt>.

== QtScript ==
The Simplified JavaScript API is powered by Qt's QtScript system which provides access to a full featured ECMA Script interpreter. If it works in ECMA Script, it will work in a Simplified JavaScript Plasmoid.

{{note|QtScript uses the high performance ECMA Script interpreter from WebKit and shares this code with QtWebKit.

However, QtScript does not include things such as a DOM API those familiar with JavaScript from a web browser context may expect. It is ''just'' ECMA Script with Qt integration.}}

On top of the ECMA Script language, QtScript provides Qt integration features. Probably the most useful one in the context of writing Plasmoids is the use of signals and slots which is Qt's callback mechanism. Signals may be emitted in QtScript by calling the signal method in question, a signal can be connected to a slot by using the connect() method (and disconnected with disconnect()) and any function defined in the Plasmoid may be used as a slot. For example:

<syntaxhighlight lang="javascript">
function onClick()
{
print("We got clicked!")
}

function onFirstClick()
{
print("First click!")
button.clicked.disconnect(onFirstClick)
}

button = new PushButton
button.clicked.connect(onClick)
button.clicked.connect(onFirstClick)
button.clicked()
</syntaxhighlight>

This will print out:

<syntaxhighlight lang="text">
We got clicked!
First click!
</syntaxhighlight>

on the console when the Plasmoid starts, and the "We got clicked!" again whenever the button is clicked by the user.

Development/Tutorials/Plasma/JavaScript/GettingStarted

2013-02-25T16:01:27Z

Tstaerk: this was very confusing. I thought this script was a "hello world" example, but it does not even explain how you execute it.

{{TutorialBrowser|

series=JavaScript Plasmoids|

name=Introduction To Writing Plasmoids with JavaScript|

next=[[../DataEngine|Getting Data: How to retrieve data from a DataEngine]]|

reading=[[../API|JavaScript Plasmoid API reference]]
}}

== Abstract ==

In this tutorial we'll cover creating a very simple Plasmoid in JavaScript, otherwise known as [http://doc.trolltech.com/latest/qtscript.html QtScript] or [http://www.ecmascript.org/ ECMAScript], to provide a Plasma widget.

Using JavaScript doesn't require any external dependencies, since it is part of the Qt libraries. As of KDE 4.3, the Plasma JavaScript engine is part of kdebase/runtime, and so can be used in any Plasma-based application, not just the Plasma Desktop.

== What is a widget? ==
In the context of Plasma, a "widget" is a single, self-contained graphical object on the canvas. They can be added and removed individually, configured separately from other widgets, etc. These "mini applications" are sometimes referred to in other widget platforms as "applets", "apps", "gadgets", "karambas", "desklets". We chose the word "widget" for Plasma as it is used by other some other existing systems.

The API of a widget is defined by the host "ScriptEngine", with the exception of native Plasma widgets written in C++ which allows plugins in loadable libraries which use the API of the Plasma library directly. Currently Plasma supports both such "native" widgets written in C++, ones written in various dynamic languages (Plasmoids) as well as:

* SuperKaramba's karambas
* Enlightenment 17 edje content
* Google Gadgets
* MacOS dashboard widgets (though not all)

These are loaded via host AppletScriptEngine plugins that bridge between the widget itself and Plasma's canvas.

== What is a Plasmoid? ==

A Plasmoid is a widget that can be loaded into Plasma that uses the native Plasma API and comes packaged in a single archive file which includes the code, metadata, images, configuration definitions, etc. Plasmoids may be currently written using various scripting languages and APIs. This tutorial covers the Simplified JavaScript API for Plasmoids

== Project Structure ==

The first step for any software project is to set up your project's directory on disk. For this tutorial we are going to create a very simple "hello-javascript" plasmoid. Create a directory on somewhere called <tt>hello-javascript</tt> which in turn contains a <tt>contents</tt> directory which then contains a <tt>code</tt> directory. This command below will do all this.
<syntaxhighlight lang="bash">
cd
mkdir -p hello-javascript/contents/code
</syntaxhighlight>

The only required part of the structure, in fact, is the <tt>contents</tt> directory - almost everything will go in this directory. But separating your code into a different directory from application data is a good habit to have.

== Metadata.desktop ==

In the <tt>hello-javascript</tt> directory create a file called <tt>metadata.desktop</tt> and open it in your text editor. Copy the following code into <tt>metadata.desktop</tt>.

<syntaxhighlight lang="ini">
[Desktop Entry]
Name=Hello JavaScript
Comment=An example JavaScript widget
Icon=chronometer

Type=Service
X-KDE-ServiceTypes=Plasma/Applet

X-Plasma-API=javascript
X-Plasma-MainScript=code/main.js
X-Plasma-DefaultSize=200,100

X-KDE-PluginInfo-Author=<Your name here>
X-KDE-PluginInfo-Email=<Your email here>
X-KDE-PluginInfo-Name=hello-javascript
X-KDE-PluginInfo-Version=1.0
X-KDE-PluginInfo-Website=http://plasma.kde.org/
X-KDE-PluginInfo-Category=Examples
X-KDE-PluginInfo-Depends=
X-KDE-PluginInfo-License=GPL
X-KDE-PluginInfo-EnabledByDefault=true
</syntaxhighlight>

This <tt>metadata.desktop</tt> file list important information needed by Plasma to load the widget, and also information about what the widget is and who created it.

<tt>Name</tt> gives the name of widget as seen by the user when they go to the Add Widget dialog on the desktop. There can be additional name entries for different languages. For example, you could add a Dutch translation by inserting the line <tt>Name[nl]=Hallo JavaScript</tt>.

<tt>Comment</tt> gives a more detailed description of the widget. This is also displayed in the Add Widget dialog, and can be translated in the same way as <tt>Name</tt>.

<tt>Icon</tt> gives the name of the icon to associate with this plasmoid. The icon is shown in the Add Widget dialog. It must be the name of an icon that is either distributed with KDE (such as <tt>chronometer</tt>) or provided by your plasmoid. If you want to provide the icon, you can use <tt>Icon=icon.png</tt>.

The <tt>Type</tt>, <tt>X-KDE-ServiceTypes</tt>, <tt>X-Plasma-API</tt> and <tt>X-Plasma-MainScript</tt> fields are required for Plasma to find your plasmoid and know what to do with it. Note that <tt>X-Plasma-MainScript</tt> is a path relative the <tt>contents</tt> directory.

<tt>X-Plasma-DefaultSize</tt> specifies the default size for widget, as <tt>width,height</tt>. While the units aren't technically pixels, they have the same value as pixels providing you don't do anything like zoom in or out on your desktop.

<tt>X-KDE-PluginInfo-Category</tt> gives a category for the widget. This is used in the Add Widgets dialog to group and filter widgets. The value must be one of the category names listed at [[Projects/Plasma/PIG]].

<tt>X-KDE-PluginInfo-Name</tt> is the internal name of the plasmoid (you can think of this as the name of the plasmoid, as opposed to the name of the widget which is given by <tt>Name</tt>). This is the name you will use as an argument to <tt>plasmoidviewer</tt> or <tt>plasmapkg</tt> when you need to provide a plasmoid name rather than a path. It doesn't have to be the same name as the directory containing <tt>metadata.desktop</tt>.

<tt>X-KDE-PluginInfo-Author</tt>, <tt>X-KDE-PluginInfo-Email</tt>, <tt>X-KDE-PluginInfo-Version</tt>, <tt>X-KDE-PluginInfo-Website</tt> and <tt>X-KDE-PluginInfo-License</tt> are informational, and are displayed in the About dialog for the plasmoid (which can be viewed by clicking the information icon next to the corresponding widget in the Add Widgets dialog of plasma).

<tt>X-KDE-PluginInfo-EnabledByDefault</tt> and <tt>X-KDE-PluginInfo-Depends</tt> rarely need to be changed from the values given here.

== Main script ==

The name of the main script file is given by <tt>X-Plasma-MainScript</tt> in metadata.desktop, and is relative to the <tt>contents</tt> directory. In our case, we will need to create the file <tt>hello-javascript/contents/code/main.js</tt>. Put the following code in it:

<syntaxhighlight lang="javascript">
layout = new LinearLayout(plasmoid);

label = new Label();
layout.addItem(label);

label.text = 'Hello JavaScript!';
</syntaxhighlight>

<strong>plasmoid</strong> is a global variable that represents your widget. It has some useful methods that we'll come to in later tutorials.

First, we create a layout, because plasmoids don't have a layout by default. This just makes sure that the label is the correct size and in the correct place. Passing <tt>plasmoid</tt> to the <tt>LinearLayout</tt> attaches the layout to the widget.

Next we add a label to the layout, and finally we set the label text.

== Testing (KDE 4.3+) ==

If you have KDE 4.3 or later, you can test your plasmoid without installing it by entering the <tt>hello-javascript</tt> directory and running <tt>plasmoidviewer</tt>. Alternatively, call
<syntaxhighlight lang="bash">
plasmoidviewer ~/hello-javascript
</syntaxhighlight>

This is very convenient for development as you can edit the Plasmoid and test the changes immediately without re-installing the plasmoid over and over again.

== Installing ==

You can install the plasmoid by running the following command from within the <tt>hello-javascript</tt> directory:
<syntaxhighlight lang="bash">
plasmapkg -i .
</syntaxhighlight>

The final argument to <tt>plasmapkg</tt> is the path to the directory containing <tt>metadata.desktop</tt> and the <tt>contents</tt> directory.

You can now add your widget to the desktop using the Add Widgets dialog, or view it by running
<syntaxhighlight lang="bash">
plasmoidviewer hello-javascript
</syntaxhighlight>

== Packaging ==

If you want to share your plasmoid, you'll have to package it. Run the following from within the <tt>hello-javascript</tt> directory:
<syntaxhighlight lang="bash">
zip -r ../hello-javascript.zip . &&
mv ../hello-javascript.zip ../hello-javascript.plasmoid
</syntaxhighlight>

You now have a plasmoid package you can share with the world. To install it, either use the "Install new widgets" functionality in the Add Widgets dialog, or go to the directory containing <tt>hello-javascript.plasmoid</tt> and run
<syntaxhighlight lang="bash">
plasmapkg -i hello-javascript.plasmoid
</syntaxhighlight>

To uninstall the plasmoid, use <tt>plasmapkg</tt> again with its -r option:
<syntaxhighlight lang="bash">
plasmapkg -r hello-javascript
</syntaxhighlight>

Note that while the argument to <tt>plasmapkg -i</tt> is a file or directory, you need to pass the plasmoid name (given by <tt>X-KDE-PluginInfo-Name</tt> in <tt>metadata.desktop</tt>) to <tt>plasmapkg -r</tt>.

== QtScript ==
The Simplified JavaScript API is powered by Qt's QtScript system which provides access to a full featured ECMA Script interpreter. If it works in ECMA Script, it will work in a Simplified JavaScript Plasmoid.

{{note|QtScript uses the high performance ECMA Script interpreter from WebKit and shares this code with QtWebKit.

However, QtScript does not include things such as a DOM API those familiar with JavaScript from a web browser context may expect. It is ''just'' ECMA Script with Qt integration.}}

On top of the ECMA Script language, QtScript provides Qt integration features. Probably the most useful one in the context of writing Plasmoids is the use of signals and slots which is Qt's callback mechanism. Signals may be emitted in QtScript by calling the signal method in question, a signal can be connected to a slot by using the connect() method (and disconnected with disconnect()) and any function defined in the Plasmoid may be used as a slot. For example:

<syntaxhighlight lang="javascript">
function onClick()
{
print("We got clicked!")
}

function onFirstClick()
{
print("First click!")
button.clicked.disconnect(onFirstClick)
}

button = new PushButton
button.clicked.connect(onClick)
button.clicked.connect(onFirstClick)
button.clicked()
</syntaxhighlight>

This will print out:

<syntaxhighlight lang="text">
We got clicked!
First click!
</syntaxhighlight>

on the console when the Plasmoid starts, and the "We got clicked!" again whenever the button is clicked by the user.

Thread:Talk:Development/Tutorials/Plasma/JavaScript/GettingStarted/good work

2013-02-25T15:45:13Z

Tstaerk: New thread: good work

good work. That's all --[[User:Tstaerk|Tstaerk]] ([[User talk:Tstaerk|talk]]) 15:45, 25 February 2013 (UTC)

Development/Tutorials/Plasma/JavaScript/GettingStarted

2013-02-25T15:44:03Z

Tstaerk: give the user a clear direction. Don't say /path/to/javascript if he does not know the path to javascript.

{{TutorialBrowser|

series=JavaScript Plasmoids|

name=Introduction To Writing Plasmoids with JavaScript|

next=[[../DataEngine|Getting Data: How to retrieve data from a DataEngine]]|

reading=[[../API|JavaScript Plasmoid API reference]]
}}

== Abstract ==

In this tutorial we'll cover creating a very simple Plasmoid in JavaScript, otherwise known as [http://doc.trolltech.com/latest/qtscript.html QtScript] or [http://www.ecmascript.org/ ECMAScript], to provide a Plasma widget.

Using JavaScript doesn't require any external dependencies, since it is part of the Qt libraries. As of KDE 4.3, the Plasma JavaScript engine is part of kdebase/runtime, and so can be used in any Plasma-based application, not just the Plasma Desktop.

== QtScript ==
The Simplified JavaScript API is powered by Qt's QtScript system which provides access to a full featured ECMA Script interpreter. If it works in ECMA Script, it will work in a Simplified JavaScript Plasmoid.

{{note|QtScript uses the high performance ECMA Script interpreter from WebKit and shares this code with QtWebKit.

However, QtScript does not include things such as a DOM API those familiar with JavaScript from a web browser context may expect. It is ''just'' ECMA Script with Qt integration.}}

On top of the ECMA Script language, QtScript provides Qt integration features. Probably the most useful one in the context of writing Plasmoids is the use of signals and slots which is Qt's callback mechanism. Signals may be emitted in QtScript by calling the signal method in question, a signal can be connected to a slot by using the connect() method (and disconnected with disconnect()) and any function defined in the Plasmoid may be used as a slot. For example:

<syntaxhighlight lang="javascript">
function onClick()
{
print("We got clicked!")
}

function onFirstClick()
{
print("First click!")
button.clicked.disconnect(onFirstClick)
}

button = new PushButton
button.clicked.connect(onClick)
button.clicked.connect(onFirstClick)
button.clicked()
</syntaxhighlight>

This will print out:

<syntaxhighlight lang="text">
We got clicked!
First click!
</syntaxhighlight>

on the console when the Plasmoid starts, and the "We got clicked!" again whenever the button is clicked by the user.

== What is a widget? ==
In the context of Plasma, a "widget" is a single, self-contained graphical object on the canvas. They can be added and removed individually, configured separately from other widgets, etc. These "mini applications" are sometimes referred to in other widget platforms as "applets", "apps", "gadgets", "karambas", "desklets". We chose the word "widget" for Plasma as it is used by other some other existing systems.

The API of a widget is defined by the host "ScriptEngine", with the exception of native Plasma widgets written in C++ which allows plugins in loadable libraries which use the API of the Plasma library directly. Currently Plasma supports both such "native" widgets written in C++, ones written in various dynamic languages (Plasmoids) as well as:

* SuperKaramba's karambas
* Enlightenment 17 edje content
* Google Gadgets
* MacOS dashboard widgets (though not all)

These are loaded via host AppletScriptEngine plugins that bridge between the widget itself and Plasma's canvas.

== What is a Plasmoid? ==

A Plasmoid is a widget that can be loaded into Plasma that uses the native Plasma API and comes packaged in a single archive file which includes the code, metadata, images, configuration definitions, etc. Plasmoids may be currently written using various scripting languages and APIs. This tutorial covers the Simplified JavaScript API for Plasmoids

== Project Structure ==

The first step for any software project is to set up your project's directory on disk. For this tutorial we are going to create a very simple "hello-javascript" plasmoid. Create a directory on somewhere called <tt>hello-javascript</tt> which in turn contains a <tt>contents</tt> directory which then contains a <tt>code</tt> directory. This command below will do all this.
<syntaxhighlight lang="bash">
cd
mkdir -p hello-javascript/contents/code
</syntaxhighlight>

The only required part of the structure, in fact, is the <tt>contents</tt> directory - almost everything will go in this directory. But separating your code into a different directory from application data is a good habit to have.

== Metadata.desktop ==

In the <tt>hello-javascript</tt> directory create a file called <tt>metadata.desktop</tt> and open it in your text editor. Copy the following code into <tt>metadata.desktop</tt>.

<syntaxhighlight lang="ini">
[Desktop Entry]
Name=Hello JavaScript
Comment=An example JavaScript widget
Icon=chronometer

Type=Service
X-KDE-ServiceTypes=Plasma/Applet

X-Plasma-API=javascript
X-Plasma-MainScript=code/main.js
X-Plasma-DefaultSize=200,100

X-KDE-PluginInfo-Author=<Your name here>
X-KDE-PluginInfo-Email=<Your email here>
X-KDE-PluginInfo-Name=hello-javascript
X-KDE-PluginInfo-Version=1.0
X-KDE-PluginInfo-Website=http://plasma.kde.org/
X-KDE-PluginInfo-Category=Examples
X-KDE-PluginInfo-Depends=
X-KDE-PluginInfo-License=GPL
X-KDE-PluginInfo-EnabledByDefault=true
</syntaxhighlight>

This <tt>metadata.desktop</tt> file list important information needed by Plasma to load the widget, and also information about what the widget is and who created it.

<tt>Name</tt> gives the name of widget as seen by the user when they go to the Add Widget dialog on the desktop. There can be additional name entries for different languages. For example, you could add a Dutch translation by inserting the line <tt>Name[nl]=Hallo JavaScript</tt>.

<tt>Comment</tt> gives a more detailed description of the widget. This is also displayed in the Add Widget dialog, and can be translated in the same way as <tt>Name</tt>.

<tt>Icon</tt> gives the name of the icon to associate with this plasmoid. The icon is shown in the Add Widget dialog. It must be the name of an icon that is either distributed with KDE (such as <tt>chronometer</tt>) or provided by your plasmoid. If you want to provide the icon, you can use <tt>Icon=icon.png</tt>.

The <tt>Type</tt>, <tt>X-KDE-ServiceTypes</tt>, <tt>X-Plasma-API</tt> and <tt>X-Plasma-MainScript</tt> fields are required for Plasma to find your plasmoid and know what to do with it. Note that <tt>X-Plasma-MainScript</tt> is a path relative the <tt>contents</tt> directory.

<tt>X-Plasma-DefaultSize</tt> specifies the default size for widget, as <tt>width,height</tt>. While the units aren't technically pixels, they have the same value as pixels providing you don't do anything like zoom in or out on your desktop.

<tt>X-KDE-PluginInfo-Category</tt> gives a category for the widget. This is used in the Add Widgets dialog to group and filter widgets. The value must be one of the category names listed at [[Projects/Plasma/PIG]].

<tt>X-KDE-PluginInfo-Name</tt> is the internal name of the plasmoid (you can think of this as the name of the plasmoid, as opposed to the name of the widget which is given by <tt>Name</tt>). This is the name you will use as an argument to <tt>plasmoidviewer</tt> or <tt>plasmapkg</tt> when you need to provide a plasmoid name rather than a path. It doesn't have to be the same name as the directory containing <tt>metadata.desktop</tt>.

<tt>X-KDE-PluginInfo-Author</tt>, <tt>X-KDE-PluginInfo-Email</tt>, <tt>X-KDE-PluginInfo-Version</tt>, <tt>X-KDE-PluginInfo-Website</tt> and <tt>X-KDE-PluginInfo-License</tt> are informational, and are displayed in the About dialog for the plasmoid (which can be viewed by clicking the information icon next to the corresponding widget in the Add Widgets dialog of plasma).

<tt>X-KDE-PluginInfo-EnabledByDefault</tt> and <tt>X-KDE-PluginInfo-Depends</tt> rarely need to be changed from the values given here.

== Main script ==

The name of the main script file is given by <tt>X-Plasma-MainScript</tt> in metadata.desktop, and is relative to the <tt>contents</tt> directory. In our case, we will need to create the file <tt>hello-javascript/contents/code/main.js</tt>. Put the following code in it:

<syntaxhighlight lang="javascript">
layout = new LinearLayout(plasmoid);

label = new Label();
layout.addItem(label);

label.text = 'Hello JavaScript!';
</syntaxhighlight>

<strong>plasmoid</strong> is a global variable that represents your widget. It has some useful methods that we'll come to in later tutorials.

First, we create a layout, because plasmoids don't have a layout by default. This just makes sure that the label is the correct size and in the correct place. Passing <tt>plasmoid</tt> to the <tt>LinearLayout</tt> attaches the layout to the widget.

Next we add a label to the layout, and finally we set the label text.

== Testing (KDE 4.3+) ==

If you have KDE 4.3 or later, you can test your plasmoid without installing it by entering the <tt>hello-javascript</tt> directory and running <tt>plasmoidviewer</tt>. Alternatively, call
<syntaxhighlight lang="bash">
plasmoidviewer ~/hello-javascript
</syntaxhighlight>

This is very convenient for development as you can edit the Plasmoid and test the changes immediately without re-installing the plasmoid over and over again.

== Installing ==

You can install the plasmoid by running the following command from within the <tt>hello-javascript</tt> directory:
<syntaxhighlight lang="bash">
plasmapkg -i .
</syntaxhighlight>

The final argument to <tt>plasmapkg</tt> is the path to the directory containing <tt>metadata.desktop</tt> and the <tt>contents</tt> directory.

You can now add your widget to the desktop using the Add Widgets dialog, or view it by running
<syntaxhighlight lang="bash">
plasmoidviewer hello-javascript
</syntaxhighlight>

== Packaging ==

If you want to share your plasmoid, you'll have to package it. Run the following from within the <tt>hello-javascript</tt> directory:
<syntaxhighlight lang="bash">
zip -r ../hello-javascript.zip . &&
mv ../hello-javascript.zip ../hello-javascript.plasmoid
</syntaxhighlight>

You now have a plasmoid package you can share with the world. To install it, either use the "Install new widgets" functionality in the Add Widgets dialog, or go to the directory containing <tt>hello-javascript.plasmoid</tt> and run
<syntaxhighlight lang="bash">
plasmapkg -i hello-javascript.plasmoid
</syntaxhighlight>

To uninstall the plasmoid, use <tt>plasmapkg</tt> again with its -r option:
<syntaxhighlight lang="bash">
plasmapkg -r hello-javascript
</syntaxhighlight>

Note that while the argument to <tt>plasmapkg -i</tt> is a file or directory, you need to pass the plasmoid name (given by <tt>X-KDE-PluginInfo-Name</tt> in <tt>metadata.desktop</tt>) to <tt>plasmapkg -r</tt>.

Development/Tutorials/Desktop File

2013-02-24T10:17:11Z

Tstaerk: /* Menus */

{{TutorialBrowser|

series=Basics|

name=Desktop File|

pre=|

next=|

reading=[http://standards.freedesktop.org/desktop-entry-spec/latest/ the .desktop Free Desktop Spec];
}}

== Desktop File ==

In order for your application to show up in menus and/or to be automatically associated with mime types in file browsers, you need to provide a .desktop file like follows:

<syntaxhighlight lang="ini">
[Desktop Entry]
Type=Application
Exec=your-app %u
MimeType=application/x-your-mime-type;
Icon=some-icon
X-DocPath=yourapp/index.html
Terminal=false
Name=Your App
GenericName=Some Generic Name
Comment=Short Description Of Your App
Categories=Qt;KDE;
</syntaxhighlight>

Take a look at [http://standards.freedesktop.org/desktop-entry-spec/latest/ the .desktop Free Desktop Spec] to find our more about the key/value pairs above. It's important to pick a good set of Categories, see the spec for a list of valid values.

== Your project ==
You want your project to show up in the K Menu like this:

[[File:Snapshot-k-menu.png]]

In this example, the application is called quickpen and it shows up in the category "Graphics". To accomplish that in your project you need to take care the .desktop file is distributed to the appropriate place.

=== qmake based projects ===
In case you are working on a qmake based project, add the following to your .pro file:
'''target.path = /usr/local/bin'''
desktop.path = /usr/share/applications
desktop.files += your-app.desktop

'''INSTALLS += target''' desktop

Note that the bold strings above should be in your project anyway.

An example .pro file can be found [https://github.com/tstaerk/quickpen/blob/dc7a5560b0cbac159d1c443572c676ee7d8fbb23/quickpen.pro here]. The related .desktop file can be found [https://github.com/tstaerk/quickpen/blob/e3b03c5949085e87a659303ae7866378f6539542/quickpen.desktop here].

=== cmake based projects ===
In case you are working on a cmake based project, add an install directive to your CMakeLists.txt file like this:
install( PROGRAMS your-app.desktop DESTINATION ${[[Development/CMake/Addons_for_KDE#The_locations_of_install_directories|XDG_APPS_INSTALL_DIR]]} )

An example CMakeLists.txt file can be found [http://quickgit.kde.org/?p=kdepim.git&a=blob&hb=18742d763bc8a2d2c2c7ef433cc66c39b6a95036&f=ktimetracker/support/CMakeLists.txt here]. The corresponding .desktop file is [http://quickgit.kde.org/?p=kdepim.git&a=blob&hb=63798b547ecb595d166cdbe2e0a04d985fcc8980&f=ktimetracker/support/ktimetracker.desktop here].

= Menus =
You can also use a .desktop file to describe KDE's context menus. Context menus are the menus that appear when you right-click onto your desktop or onto a file or folder. Let's write a context menu for konqueror that counts the lines in a file.

To do this, change directory to your Service Menu directory:
$ kde4-config --path services
/home/knoppix/.kde/share/kde4/services/:/usr/share/kde4/services/
$ cd /usr/share/kde4/services/ServiceMenus/

Create a desktop file with any name, e.g. count.desktop with the following content:

[Desktop Entry]
Type=Service
ServiceTypes=KonqPopupMenu/Plugin
MimeType=all/all;
Actions=countlines;
X-KDE-Submenu=Count
X-KDE-StartupNotify=false
X-KDE-Priority=TopLevel

[Desktop Action countlines]
Name=Count lines
Exec=kdialog --msgbox "$(wc -l %F)"

It will look like this:

[[File:Snapshot-file-context-menu-kde-2.png]]

Some remarks:
* it is possible to translate the strings the user sees. For a German translation you could add below X-KDE-Submenu=Count:
X-KDE-Submenu[de]=Zaehlen
* this context menu entry will not only appear in Konqueror, but also e.g. in Dolphin.
* if you want this to work as a menu item, not as a submenu, just delete the line
X-KDE-Submenu=Count

= See also =
* [http://standards.freedesktop.org/desktop-entry-spec/latest/ FreeDeskTop's specification about Desktop entries]

[[Category:Programming]]
[[Category:Tutorial]]
[[Category:FAQs]]

Development/Tutorials/Desktop File

2013-02-24T10:10:21Z

Tstaerk: /* Menus */

{{TutorialBrowser|

series=Basics|

name=Desktop File|

pre=|

next=|

reading=[http://standards.freedesktop.org/desktop-entry-spec/latest/ the .desktop Free Desktop Spec];
}}

== Desktop File ==

In order for your application to show up in menus and/or to be automatically associated with mime types in file browsers, you need to provide a .desktop file like follows:

<syntaxhighlight lang="ini">
[Desktop Entry]
Type=Application
Exec=your-app %u
MimeType=application/x-your-mime-type;
Icon=some-icon
X-DocPath=yourapp/index.html
Terminal=false
Name=Your App
GenericName=Some Generic Name
Comment=Short Description Of Your App
Categories=Qt;KDE;
</syntaxhighlight>

Take a look at [http://standards.freedesktop.org/desktop-entry-spec/latest/ the .desktop Free Desktop Spec] to find our more about the key/value pairs above. It's important to pick a good set of Categories, see the spec for a list of valid values.

== Your project ==
You want your project to show up in the K Menu like this:

[[File:Snapshot-k-menu.png]]

In this example, the application is called quickpen and it shows up in the category "Graphics". To accomplish that in your project you need to take care the .desktop file is distributed to the appropriate place.

=== qmake based projects ===
In case you are working on a qmake based project, add the following to your .pro file:
'''target.path = /usr/local/bin'''
desktop.path = /usr/share/applications
desktop.files += your-app.desktop

'''INSTALLS += target''' desktop

Note that the bold strings above should be in your project anyway.

An example .pro file can be found [https://github.com/tstaerk/quickpen/blob/dc7a5560b0cbac159d1c443572c676ee7d8fbb23/quickpen.pro here]. The related .desktop file can be found [https://github.com/tstaerk/quickpen/blob/e3b03c5949085e87a659303ae7866378f6539542/quickpen.desktop here].

=== cmake based projects ===
In case you are working on a cmake based project, add an install directive to your CMakeLists.txt file like this:
install( PROGRAMS your-app.desktop DESTINATION ${[[Development/CMake/Addons_for_KDE#The_locations_of_install_directories|XDG_APPS_INSTALL_DIR]]} )

An example CMakeLists.txt file can be found [http://quickgit.kde.org/?p=kdepim.git&a=blob&hb=18742d763bc8a2d2c2c7ef433cc66c39b6a95036&f=ktimetracker/support/CMakeLists.txt here]. The corresponding .desktop file is [http://quickgit.kde.org/?p=kdepim.git&a=blob&hb=63798b547ecb595d166cdbe2e0a04d985fcc8980&f=ktimetracker/support/ktimetracker.desktop here].

= Menus =
You can also use a .desktop file to describe KDE's context menus. Context menus are the menus that appear when you right-click onto your desktop or onto a file or folder. Let's write a context menu for konqueror that counts the lines in a file.

To do this, change directory to your Service Menu directory:
$ kde4-config --path services
/home/knoppix/.kde/share/kde4/services/:/usr/share/kde4/services/
$ cd /usr/share/kde4/services/ServiceMenus/

Create a desktop file with any name, e.g. count.desktop with the following content:

[Desktop Entry]
Type=Service
ServiceTypes=KonqPopupMenu/Plugin
MimeType=all/all;
Actions=countlines;
X-KDE-Submenu=Count
X-KDE-StartupNotify=false
X-KDE-Priority=TopLevel

[Desktop Action countlines]
Name=Count lines
Exec=kdialog --msgbox "$(wc -l %F)"

It will look like this:

[[File:Snapshot-file-context-menu-kde-2.png]]

Some remarks:
* it is possible to translate the strings the user sees. For a German translation you could add below X-KDE-Submenu=Count:
X-KDE-Submenu[de]=Zaehlen
* this context menu entry will not only appear in Konqueror, but also e.g. in Dolphin.

= See also =
* [http://standards.freedesktop.org/desktop-entry-spec/latest/ FreeDeskTop's specification about Desktop entries]

[[Category:Programming]]
[[Category:Tutorial]]
[[Category:FAQs]]

File:Snapshot-file-context-menu-kde-2.png

2013-02-24T10:07:08Z

Tstaerk:

Development/Tutorials/Desktop File

2013-02-24T10:01:35Z

Tstaerk: /* Menus */

{{TutorialBrowser|

series=Basics|

name=Desktop File|

pre=|

next=|

reading=[http://standards.freedesktop.org/desktop-entry-spec/latest/ the .desktop Free Desktop Spec];
}}

== Desktop File ==

In order for your application to show up in menus and/or to be automatically associated with mime types in file browsers, you need to provide a .desktop file like follows:

<syntaxhighlight lang="ini">
[Desktop Entry]
Type=Application
Exec=your-app %u
MimeType=application/x-your-mime-type;
Icon=some-icon
X-DocPath=yourapp/index.html
Terminal=false
Name=Your App
GenericName=Some Generic Name
Comment=Short Description Of Your App
Categories=Qt;KDE;
</syntaxhighlight>

Take a look at [http://standards.freedesktop.org/desktop-entry-spec/latest/ the .desktop Free Desktop Spec] to find our more about the key/value pairs above. It's important to pick a good set of Categories, see the spec for a list of valid values.

== Your project ==
You want your project to show up in the K Menu like this:

[[File:Snapshot-k-menu.png]]

In this example, the application is called quickpen and it shows up in the category "Graphics". To accomplish that in your project you need to take care the .desktop file is distributed to the appropriate place.

=== qmake based projects ===
In case you are working on a qmake based project, add the following to your .pro file:
'''target.path = /usr/local/bin'''
desktop.path = /usr/share/applications
desktop.files += your-app.desktop

'''INSTALLS += target''' desktop

Note that the bold strings above should be in your project anyway.

An example .pro file can be found [https://github.com/tstaerk/quickpen/blob/dc7a5560b0cbac159d1c443572c676ee7d8fbb23/quickpen.pro here]. The related .desktop file can be found [https://github.com/tstaerk/quickpen/blob/e3b03c5949085e87a659303ae7866378f6539542/quickpen.desktop here].

=== cmake based projects ===
In case you are working on a cmake based project, add an install directive to your CMakeLists.txt file like this:
install( PROGRAMS your-app.desktop DESTINATION ${[[Development/CMake/Addons_for_KDE#The_locations_of_install_directories|XDG_APPS_INSTALL_DIR]]} )

An example CMakeLists.txt file can be found [http://quickgit.kde.org/?p=kdepim.git&a=blob&hb=18742d763bc8a2d2c2c7ef433cc66c39b6a95036&f=ktimetracker/support/CMakeLists.txt here]. The corresponding .desktop file is [http://quickgit.kde.org/?p=kdepim.git&a=blob&hb=63798b547ecb595d166cdbe2e0a04d985fcc8980&f=ktimetracker/support/ktimetracker.desktop here].

= Menus =
You can also use a .desktop file to describe KDE's context menus. Context menus are the menus that appear when you right-click onto your desktop or onto a file or folder. Let's write a context menu for konqueror that counts the lines in a file.

To do this, change directory to your Service Menu directory:
$ kde4-config --path services
/home/knoppix/.kde/share/kde4/services/:/usr/share/kde4/services/
$ cd /usr/share/kde4/services/ServiceMenus/

Create a desktop file with any name, e.g. count.desktop with the following content:

[Desktop Entry]
Type=Service
ServiceTypes=KonqPopupMenu/Plugin
MimeType=all/all;
Actions=countlines;
X-KDE-Submenu=Count
X-KDE-StartupNotify=false
X-KDE-Priority=TopLevel

[Desktop Action countlines]
Name=Count lines
Exec=kdialog --msgbox "$(wc -l %F)"

Some remarks:
* it is possible to translate the strings the user sees. For a German translation you could add below X-KDE-Submenu=Count:
X-KDE-Submenu[de]=Zaehlen
* this context menu entry will not only appear in Konqueror, but also e.g. in Dolphin.

= See also =
* [http://standards.freedesktop.org/desktop-entry-spec/latest/ FreeDeskTop's specification about Desktop entries]

[[Category:Programming]]
[[Category:Tutorial]]
[[Category:FAQs]]

Development/Tutorials/Desktop File

2013-02-24T09:48:36Z

Tstaerk: /* Menus */

{{TutorialBrowser|

series=Basics|

name=Desktop File|

pre=|

next=|

reading=[http://standards.freedesktop.org/desktop-entry-spec/latest/ the .desktop Free Desktop Spec];
}}

== Desktop File ==

In order for your application to show up in menus and/or to be automatically associated with mime types in file browsers, you need to provide a .desktop file like follows:

<syntaxhighlight lang="ini">
[Desktop Entry]
Type=Application
Exec=your-app %u
MimeType=application/x-your-mime-type;
Icon=some-icon
X-DocPath=yourapp/index.html
Terminal=false
Name=Your App
GenericName=Some Generic Name
Comment=Short Description Of Your App
Categories=Qt;KDE;
</syntaxhighlight>

Take a look at [http://standards.freedesktop.org/desktop-entry-spec/latest/ the .desktop Free Desktop Spec] to find our more about the key/value pairs above. It's important to pick a good set of Categories, see the spec for a list of valid values.

== Your project ==
You want your project to show up in the K Menu like this:

[[File:Snapshot-k-menu.png]]

In this example, the application is called quickpen and it shows up in the category "Graphics". To accomplish that in your project you need to take care the .desktop file is distributed to the appropriate place.

=== qmake based projects ===
In case you are working on a qmake based project, add the following to your .pro file:
'''target.path = /usr/local/bin'''
desktop.path = /usr/share/applications
desktop.files += your-app.desktop

'''INSTALLS += target''' desktop

Note that the bold strings above should be in your project anyway.

An example .pro file can be found [https://github.com/tstaerk/quickpen/blob/dc7a5560b0cbac159d1c443572c676ee7d8fbb23/quickpen.pro here]. The related .desktop file can be found [https://github.com/tstaerk/quickpen/blob/e3b03c5949085e87a659303ae7866378f6539542/quickpen.desktop here].

=== cmake based projects ===
In case you are working on a cmake based project, add an install directive to your CMakeLists.txt file like this:
install( PROGRAMS your-app.desktop DESTINATION ${[[Development/CMake/Addons_for_KDE#The_locations_of_install_directories|XDG_APPS_INSTALL_DIR]]} )

An example CMakeLists.txt file can be found [http://quickgit.kde.org/?p=kdepim.git&a=blob&hb=18742d763bc8a2d2c2c7ef433cc66c39b6a95036&f=ktimetracker/support/CMakeLists.txt here]. The corresponding .desktop file is [http://quickgit.kde.org/?p=kdepim.git&a=blob&hb=63798b547ecb595d166cdbe2e0a04d985fcc8980&f=ktimetracker/support/ktimetracker.desktop here].

= Menus =
You can also use a .desktop file to describe KDE's context menus. Context menus are the menus that appear when you right-click onto your desktop or onto a file or folder. Let's write a context menu for konqueror that counts the lines in a file.

To do this, change directory to your Service Menu directory:
$ kde4-config --path services
/home/knoppix/.kde/share/kde4/services/:/usr/share/kde4/services/
$ cd /usr/share/kde4/services/ServiceMenus/

Create a desktop file with any name, e.g. count.desktop with the following content:

[Desktop Entry]
Type=Service
ServiceTypes=KonqPopupMenu/Plugin
MimeType=all/all;
Actions=countlines;
X-KDE-Submenu=Count
X-KDE-StartupNotify=false
X-KDE-Priority=TopLevel

[Desktop Action countlines]
Name=Count lines
Exec=kdialog --msgbox "$(wc -l %F)"

= See also =
* [http://standards.freedesktop.org/desktop-entry-spec/latest/ FreeDeskTop's specification about Desktop entries]

[[Category:Programming]]
[[Category:Tutorial]]
[[Category:FAQs]]

Development/Tutorials/Desktop File

2013-02-24T08:54:55Z

Tstaerk: menus

{{TutorialBrowser|

series=Basics|

name=Desktop File|

pre=|

next=|

reading=[http://standards.freedesktop.org/desktop-entry-spec/latest/ the .desktop Free Desktop Spec];
}}

== Desktop File ==

In order for your application to show up in menus and/or to be automatically associated with mime types in file browsers, you need to provide a .desktop file like follows:

<syntaxhighlight lang="ini">
[Desktop Entry]
Type=Application
Exec=your-app %u
MimeType=application/x-your-mime-type;
Icon=some-icon
X-DocPath=yourapp/index.html
Terminal=false
Name=Your App
GenericName=Some Generic Name
Comment=Short Description Of Your App
Categories=Qt;KDE;
</syntaxhighlight>

Take a look at [http://standards.freedesktop.org/desktop-entry-spec/latest/ the .desktop Free Desktop Spec] to find our more about the key/value pairs above. It's important to pick a good set of Categories, see the spec for a list of valid values.

== Your project ==
You want your project to show up in the K Menu like this:

[[File:Snapshot-k-menu.png]]

In this example, the application is called quickpen and it shows up in the category "Graphics". To accomplish that in your project you need to take care the .desktop file is distributed to the appropriate place.

=== qmake based projects ===
In case you are working on a qmake based project, add the following to your .pro file:
'''target.path = /usr/local/bin'''
desktop.path = /usr/share/applications
desktop.files += your-app.desktop

'''INSTALLS += target''' desktop

Note that the bold strings above should be in your project anyway.

An example .pro file can be found [https://github.com/tstaerk/quickpen/blob/dc7a5560b0cbac159d1c443572c676ee7d8fbb23/quickpen.pro here]. The related .desktop file can be found [https://github.com/tstaerk/quickpen/blob/e3b03c5949085e87a659303ae7866378f6539542/quickpen.desktop here].

=== cmake based projects ===
In case you are working on a cmake based project, add an install directive to your CMakeLists.txt file like this:
install( PROGRAMS your-app.desktop DESTINATION ${[[Development/CMake/Addons_for_KDE#The_locations_of_install_directories|XDG_APPS_INSTALL_DIR]]} )

An example CMakeLists.txt file can be found [http://quickgit.kde.org/?p=kdepim.git&a=blob&hb=18742d763bc8a2d2c2c7ef433cc66c39b6a95036&f=ktimetracker/support/CMakeLists.txt here]. The corresponding .desktop file is [http://quickgit.kde.org/?p=kdepim.git&a=blob&hb=63798b547ecb595d166cdbe2e0a04d985fcc8980&f=ktimetracker/support/ktimetracker.desktop here].

= Menus =
You can also use a .desktop file to describe KDE's context menus. For example have a look at /usr/share/kde4/services/ServiceMenus/ark_addtoservicemenu.desktop

= See also =
* [http://standards.freedesktop.org/desktop-entry-spec/latest/ FreeDeskTop's specification about Desktop entries]

[[Category:Programming]]
[[Category:Tutorial]]
[[Category:FAQs]]

Development/Tutorials/Desktop File

2013-02-24T08:04:47Z

Tstaerk: KDE's context menu

{{TutorialBrowser|

series=Basics|

name=Desktop File|

pre=|

next=|

reading=[http://standards.freedesktop.org/desktop-entry-spec/latest/ the .desktop Free Desktop Spec];
}}

== Desktop File ==

In order for your application to show up in menus and/or to be automatically associated with mime types in file browsers, you need to provide a .desktop file like follows:

<syntaxhighlight lang="ini">
[Desktop Entry]
Type=Application
Exec=your-app %u
MimeType=application/x-your-mime-type;
Icon=some-icon
X-DocPath=yourapp/index.html
Terminal=false
Name=Your App
GenericName=Some Generic Name
Comment=Short Description Of Your App
Categories=Qt;KDE;
</syntaxhighlight>

Take a look at [http://standards.freedesktop.org/desktop-entry-spec/latest/ the .desktop Free Desktop Spec] to find our more about the key/value pairs above. It's important to pick a good set of Categories, see the spec for a list of valid values.

== Your project ==
You want your project to show up in the K Menu like this:

[[File:Snapshot-k-menu.png]]

In this example, the application is called quickpen and it shows up in the category "Graphics". To accomplish that in your project you need to take care the .desktop file is distributed to the appropriate place.

=== qmake based projects ===
In case you are working on a qmake based project, add the following to your .pro file:
'''target.path = /usr/local/bin'''
desktop.path = /usr/share/applications
desktop.files += your-app.desktop

'''INSTALLS += target''' desktop

Note that the bold strings above should be in your project anyway.

An example .pro file can be found [https://github.com/tstaerk/quickpen/blob/dc7a5560b0cbac159d1c443572c676ee7d8fbb23/quickpen.pro here]. The related .desktop file can be found [https://github.com/tstaerk/quickpen/blob/e3b03c5949085e87a659303ae7866378f6539542/quickpen.desktop here].

=== cmake based projects ===
In case you are working on a cmake based project, add an install directive to your CMakeLists.txt file like this:
install( PROGRAMS your-app.desktop DESTINATION ${[[Development/CMake/Addons_for_KDE#The_locations_of_install_directories|XDG_APPS_INSTALL_DIR]]} )

An example CMakeLists.txt file can be found [http://quickgit.kde.org/?p=kdepim.git&a=blob&hb=18742d763bc8a2d2c2c7ef433cc66c39b6a95036&f=ktimetracker/support/CMakeLists.txt here]. The corresponding .desktop file is [http://quickgit.kde.org/?p=kdepim.git&a=blob&hb=63798b547ecb595d166cdbe2e0a04d985fcc8980&f=ktimetracker/support/ktimetracker.desktop here].

= More =
You can also use a .desktop file to describe KDE's context menu.

= See also =
* [http://standards.freedesktop.org/desktop-entry-spec/latest/ FreeDeskTop's specification about Desktop entries]

[[Category:Programming]]
[[Category:Tutorial]]
[[Category:FAQs]]

Getting Started/Build/kdesrc-build

2013-01-27T10:10:05Z

Tstaerk: subversion -> git

{{note|It is possible to build KDE 3 using older versions of kdesrc-build, but this is not described here.}}

== Building KDE using the kdesrc-build tool ==

=== Introduction to kdesrc-build ===

[http://kdesrc-build.kde.org/ kdesrc-build] (formerly kdesvn-build) is a tool to allow users and developers to easily download and build the latest versions of the [http://www.kde.org/ KDE Software Compilation] (KDE SC) from the KDE source code repositories. It automates the following tasks and more:

* Performing the initial checkout.
* Handling updates for modules that are already checked out.
* Setting up the build system for the module.
* Performing the build and install.
* Specifying your CMake options or configure flags (so you don't have to remember them every time).
* Logging build errors so you can review them easier for troubleshooting.

It is not the end-all for your troubles building KDE, [[../Troubleshooting|Troubleshooting]] still applies. Many errors that occur using other methods occur here too, you read the log files that are stored for you.

=== Why use kdesrc-build? ===

So why use kdesrc-build? There are several reasons you may like to use it:

# Less manual editing of commands. Instead of having to remember to add the correct options to the cmake command line or configure command, you can setup the options once and then kdesrc-build will use your settings from then on, saving you from wasting time because you forgot to enable a setting.
# Command logging to help debug build failures. kdesrc-build logs all command outputs to a file. This has several advantages:
## When a module fails to build, you already have the error output saved to disk, ready to be viewed and compared with other error messages to aid debugging.
## Quieter output. Even with CMake, the output of Qt or a KDE SC module build can be extensive. kdesrc-build does not show the details of a module build (but will show the progress), instead an overview of the build process is displayed.
# It's just easier. Instead of having to learn how to use the Subversion and git tools, and how to setup a KDE build system, you can specify what modules you want build, where to install them to, and any other options you want and then have kdesrc-build actually do it, even while you're away from the computer or busy doing other things.
# It's easy to step in yourself. kdesrc-build uses a standard source and build directory layout, and calls the same commands you would. So kdesrc-build will not interfere with you performing the build or editing the source yourself if you so choose.

=== Setting up ===

==== Prerequisites ====
kdesrc-build is fairly easy to install and setup, but you also need to have the right software installed to build KDE. The requirements to build KDE are available as follows:

* KDE 4: [[../Requirements|KDE 4 Requirements]]

kdesrc-build requires Perl 5.10 or higher. It is installed by default with most distributions, and is included in the link above. Check your version of Perl with:
<syntaxhighlight lang="text">perl -v</syntaxhighlight>

You will also need [https://github.com/gisle/libwww-perl#readme libwww] (sometimes called LWP), a collection of Perl Internet-related modules, and [http://search.cpan.org/~toddr/XML-Parser/Parser.pm XML::Parser] to support the XML-based KDE Project database. Both of these modules are extremely common and should be available in your distribution's packager manager. For example for SUSE install them with
yast -i perl-libwww-perl

kdesrc-build itself may be packaged on your distribution, which allows you to easily install its dependencies as well. ([http://packages.debian.org/unstable/main/kdesrc-build Debian provides packages] and a Fedora package is pending a fix to the kdesrc-build sources).

{{note|kdesrc-build is developed on a Linux system, but it should work on the various BSD distributions as well (although GNU tools may be required).}}

==== Download and install kdesrc-build ====
Download kdesrc from git like this:
<syntaxhighlight lang="bash">
git clone git://anongit.kde.org/kdesrc-build.git ~/kdesrc
</syntaxhighlight>

==== Setup the configuration ====
Now you should [[Getting Started/Build/kdesrc-build-config|setup your configuration]]. For the most part the defaults in the included kdesrc-buildrc-sample should be sufficient.

<syntaxhighlight lang="bash">
cp ~/kdesrc-build/kdesrc-buildrc-sample ~/.kdesrc-buildrc
</syntaxhighlight>

Now you can start kdesrc-build using the commands
cd
./kdesrc-build/kdesrc-build

Now you can edit the configuration file ~/.kdesrc-buildrc

{{tip|Note that the config file's name begins with a leading ., making it a hidden file. You may need to show hidden files in Dolphin or Konqueror to find the configuration file to edit it. Or, you can edit the sample before copying it to ~/.kdesrc-buildrc.}}

Also, make sure that the modules you'll want to build are included. You'll want the following at the least:

* qt-copy, kdesupport, kdelibs, kdepimlibs, kdebase

Modules are built in the order they appear in your ~/.kdesrc-buildrc, so the first module should be qt-copy, kdelibs should be before any other KDE SC module, and so on.

{{note|The sample configuration file does include these modules by default, you won't need to make many changes unless you'd like to add some modules to the build by uncommenting them.}}

You may want to enable the make-install-prefix option if you are installing KDE SC or Qt to a directory that is not in your home directory. make-install-prefix allows you to run su or sudo during the make install process so you can install files as root, or set certain programs to execute with higher permissions (This is required for certain programs to execute properly).

<pre>module kdelibs
make-install-prefix sudo -S # sudo with no stdin
end module

module kdebase
make-install-prefix sudo -S
end module</pre>

If a module you'd like to build isn't already present, simply add

<pre>module <module-name>
end module</pre> at the end of the ~/.kdesrc-buildrc. <module-name> would be whatever the module is called in the software repository (for instance, kdemultimedia).

===== Git-based modules =====

Some KDE projects use the "git" source-control software instead of Subversion (as part of an ongoing migration to git). This includes software like Amarok and Konversation.

To build these modules in kdesrc-build, you just need to add a couple of lines to the module configuration. For example, konversation is developed in the Git repository at [https://projects.kde.org/projects/extragear/network/konversation/repository]. So you would just add a module (you can pick whatever name for the module you like, as long as it's not already used):

<pre>module konversation
repository git://anongit.kde.org/konversation
branch master
end module</pre>

In this case I selected the "master" branch since that is the default git branch.

Now whenever you build konversation, kdesrc-build will use git instead of Subversion.

==== Useful kdesrc-build commands ====
kdesrc-build is driven from the command line, so here's a guide to some of the more useful command line options:

<table cellpadding="2">
<tr>
<th>Option</th><th>Effect</th>
</tr>
<tr>
<td><tt><span style="white-space:nowrap;">[http://kdesrc-build.kde.org/documentation/cmdline.html#cmdline-pretend --pretend]</span></tt> (Short form <tt><span style="white-space:nowrap;">-p</span></tt>)</td>
<td>This option is like a dry run. kdesrc-build will process the options and its configuration like normal, and run through the build as normal, but instead of downloading or running the build will instead output what kdesrc-build would have done. You should always run with -p before running kdesrc-build to make sure it is doing what you expect.</td>
</tr>
<tr>
<td><tt>[http://kdesrc-build.kde.org/documentation/cmdline.html#cmdline-no-svn --no-svn]</tt> (Alt. form <tt>--no-src</tt>)</td><td>This option skips the source code update step. This is useful if you're running kdesrc-build again soon after the last update and don't want to wait to find out there were no changes.</td>
</tr>
<tr>
<td><tt>[http://kdesrc-build.kde.org/documentation/cmdline.html#cmdline-refresh-build --refresh-build]</tt></td><td>This option causes kdesrc-build to delete the current build information for the given modules and start building them again from scratch. This option takes a lot of time but gives the best chance of a successful build.</td>
</tr>
</table>

Any other non-option arguments on the command line are assumed to be modules to build (and are built in the order provided on the command line). If no modules are specified, all of the modules listed in the ~/.kdesrc-buildrc are built in the order listed in the file.

== Build ==
We're almost there. If you're happy with your settings then it's time to test out kdesrc-build. In theory things are as simple as running kdesrc-build and then coming back later. ;)

<syntaxhighlight lang="bash">
cd ~/kdesrc
./kdesrc-build
</syntaxhighlight>

You may want to test by building qt-copy first however.

<syntaxhighlight lang="bash">
cd ~/kdesrc
./kdesrc-build qt-copy
</syntaxhighlight>

{{tip|If you have the [http://www.gnu.org/software/screen/ GNU screen] program available then you should definitely use it to run kdesrc-build, as you can detach your kdesrc-build session and logout while kdesrc-build is still running.}}

If the build failed (kdesrc-build will error out with a nice bright red error message) then there are several possibilities:

# You are missing a key piece of required software (such as a development library)
# The KDE SC code being compiled is broken in some fashion to where it won't build. This is commonly due to newly committed code that worked on the developer's machine, or occasionally on Mondays (when incompatible changes are permitted to kdelibs).
# kdesrc-build is not setup properly. You may be trying to install to a directory that you have no permissions to access for instance, or you may have specified a system qtdir that does not exist.
# The module may depend on a newer version of qt-copy or kdelibs (or other module). In this case you'll have to run kdesrc-build to update the out-of-date module first.

How do you find out what the error was? The output of the failing command will be in the log directory. By default, all log output is in the {{path|log}} subdirectory of the KDE SC source directory. The log directory is laid out like this: {{path|log/date-run/module/output-file.log}}. To simplify finding the appropriate file, there are a couple of symlinks created:

{{path|log/latest}} always has the debugging output for the last time kdesrc-build was run (--pretend doesn't count toward this)
{{path|log/latest/<module>/error.log}} has the debugging output for the command that caused a module build to fail.

For instance if qt-copy just failed to build you could read the output like this:

<syntaxhighlight lang="bash">
cd ~/kderc
kwrite log/latest/qt-copy/error.log
</syntaxhighlight>

Replace kwrite with your preferred editor. Hopefully the output can guide you to resolving the problem. For instance, if the failure is a cmake output saying you're missing a library, install that library and try again. ;) For link errors you can try running a --refresh-build on the module (or if that doesn't work, required libraries like qt-copy and kdelibs).

If you're stumped by the error you may want to wait a day and try updating again, and hope that the reason for the error has been fixed. You can also try mailing the [http://www.kde.org/mailinglists/ kde-devel] mailing list to see if others know about the problem or have had similar issues.

== Running KDE ==

Assuming you got enough of the modules to build and install to have a working KDE installation, you'll still need to setup your environment correctly to run it. kdesrc-build doesn't help you out here (yet), so you should follow the instructions [[Getting_Started/Using_an_IDE_with_KDE4|here]].

Make sure to use the same paths as the ones you defined in .kdesrc-buildrc: for the KDEDIRS and KDEDIR variable use the setting of the "prefix" option (in the global section). For the QTDIR variable use the setting of the "qtdir" option.

== Keeping KDE up to date ==

Keeping your KDE installation up to date is as simple as running kdesrc-build again. Every kdesrc-build has these phases:

# Update the source code for all modules being built.
# Build and then install all the modules.

Old build directories are not deleted by default, so the build after a small update will not normally take as long as the initial build of a module. This is called "incremental make". However it may be necessary at times to perform a full rebuild due to inconsistencies between the build directory configuation and changes to the source directory. You can use the --refresh-build option to force a full rebuild.

For more information on how to take advantage of kdesrc-build, see the [http://kdesrc-build.kde.org/documentation online documentation] for kdesrc-build, which describes all of the module options and command line options available for kdesrc-build and gives tips on how to perform various useful tasks.

If you have any questions that are not answered please feel free to add them under the Discussion entry for this page and hopefully someone will be able to get the answer.

= See also =
* To browse kdesrc-build's git repository, use [http://quickgit.kde.org/?p=kdesrc-build.git GitWeb].
* The Nokia Qt toolkit used by KDE can be browsed at [http://qt.gitorious.org/qt Nokia's Qt version on gitorious].

[[Category:Build_KDE]]
[[Category:Tutorial]]

Getting Started/Build/kdesrc-build

2013-01-27T09:32:57Z

Tstaerk: /* Setup the configuration */

{{note|It is possible to build KDE 3 using older versions of kdesrc-build, but this is not described here.}}

== Building KDE using the kdesrc-build tool ==

=== Introduction to kdesrc-build ===

[http://kdesrc-build.kde.org/ kdesrc-build] (formerly kdesvn-build) is a tool to allow users and developers to easily download and build the latest versions of the [http://www.kde.org/ KDE Software Compilation] (KDE SC) from the KDE source code repositories. It automates the following tasks and more:

* Performing the initial checkout.
* Handling updates for modules that are already checked out.
* Setting up the build system for the module.
* Performing the build and install.
* Specifying your CMake options or configure flags (so you don't have to remember them every time).
* Logging build errors so you can review them easier for troubleshooting.

It is not the end-all for your troubles building KDE, [[../Troubleshooting|Troubleshooting]] still applies. Many errors that occur using other methods occur here too, you read the log files that are stored for you.

=== Why use kdesrc-build? ===

So why use kdesrc-build? There are several reasons you may like to use it:

# Less manual editing of commands. Instead of having to remember to add the correct options to the cmake command line or configure command, you can setup the options once and then kdesrc-build will use your settings from then on, saving you from wasting time because you forgot to enable a setting.
# Command logging to help debug build failures. kdesrc-build logs all command outputs to a file. This has several advantages:
## When a module fails to build, you already have the error output saved to disk, ready to be viewed and compared with other error messages to aid debugging.
## Quieter output. Even with CMake, the output of Qt or a KDE SC module build can be extensive. kdesrc-build does not show the details of a module build (but will show the progress), instead an overview of the build process is displayed.
# It's just easier. Instead of having to learn how to use the Subversion and git tools, and how to setup a KDE build system, you can specify what modules you want build, where to install them to, and any other options you want and then have kdesrc-build actually do it, even while you're away from the computer or busy doing other things.
# It's easy to step in yourself. kdesrc-build uses a standard source and build directory layout, and calls the same commands you would. So kdesrc-build will not interfere with you performing the build or editing the source yourself if you so choose.

=== Setting up ===

==== Prerequisites ====
kdesrc-build is fairly easy to install and setup, but you also need to have the right software installed to build KDE. The requirements to build KDE are available as follows:

* KDE 4: [[../Requirements|KDE 4 Requirements]]

kdesrc-build requires Perl 5.10 or higher. It is installed by default with most distributions, and is included in the link above. Check your version of Perl with:
<syntaxhighlight lang="text">perl -v</syntaxhighlight>

You will also need [https://github.com/gisle/libwww-perl#readme libwww] (sometimes called LWP), a collection of Perl Internet-related modules, and [http://search.cpan.org/~toddr/XML-Parser/Parser.pm XML::Parser] to support the XML-based KDE Project database. Both of these modules are extremely common and should be available in your distribution's packager manager. For example for SUSE install them with
yast -i perl-libwww-perl

kdesrc-build itself may be packaged on your distribution, which allows you to easily install its dependencies as well. ([http://packages.debian.org/unstable/main/kdesrc-build Debian provides packages] and a Fedora package is pending a fix to the kdesrc-build sources).

{{note|kdesrc-build is developed on a Linux system, but it should work on the various BSD distributions as well (although GNU tools may be required).}}

==== Download and install kdesrc-build ====
Download kdesrc from git like this:
<syntaxhighlight lang="bash">
git clone git://anongit.kde.org/kdesrc-build.git ~/kdesrc
</syntaxhighlight>

==== Setup the configuration ====
Now you should [[Getting Started/Build/kdesrc-build-config|setup your configuration]]. For the most part the defaults in the included kdesrc-buildrc-sample should be sufficient.

<syntaxhighlight lang="bash">
cp ~/kdesrc-build/kdesrc-buildrc-sample ~/.kdesrc-buildrc
</syntaxhighlight>

Now you can start kdesrc-build using the commands
cd
./kdesrc-build/kdesrc-build

Now you can edit the configuration file ~/.kdesrc-buildrc

{{tip|Note that the config file's name begins with a leading ., making it a hidden file. You may need to show hidden files in Dolphin or Konqueror to find the configuration file to edit it. Or, you can edit the sample before copying it to ~/.kdesrc-buildrc.}}

Also, make sure that the modules you'll want to build are included. You'll want the following at the least:

* qt-copy, kdesupport, kdelibs, kdepimlibs, kdebase

Modules are built in the order they appear in your ~/.kdesrc-buildrc, so the first module should be qt-copy, kdelibs should be before any other KDE SC module, and so on.

{{note|The sample configuration file does include these modules by default, you won't need to make many changes unless you'd like to add some modules to the build by uncommenting them.}}

You may want to enable the make-install-prefix option if you are installing KDE SC or Qt to a directory that is not in your home directory. make-install-prefix allows you to run su or sudo during the make install process so you can install files as root, or set certain programs to execute with higher permissions (This is required for certain programs to execute properly).

<pre>module kdelibs
make-install-prefix sudo -S # sudo with no stdin
end module

module kdebase
make-install-prefix sudo -S
end module</pre>

If a module you'd like to build isn't already present, simply add

<pre>module <module-name>
end module</pre> at the end of the ~/.kdesrc-buildrc. <module-name> would be whatever the module is called in the software repository (for instance, kdemultimedia).

===== Git-based modules =====

Some KDE projects use the "git" source-control software instead of Subversion (as part of an ongoing migration to git). This includes software like Amarok and Konversation.

To build these modules in kdesrc-build, you just need to add a couple of lines to the module configuration. For example, konversation is developed in the Git repository at [https://projects.kde.org/projects/extragear/network/konversation/repository]. So you would just add a module (you can pick whatever name for the module you like, as long as it's not already used):

<pre>module konversation
repository git://anongit.kde.org/konversation
branch master
end module</pre>

In this case I selected the "master" branch since that is the default git branch.

Now whenever you build konversation, kdesrc-build will use git instead of Subversion.

==== Useful kdesrc-build commands ====
kdesrc-build is driven from the command line, so here's a guide to some of the more useful command line options:

<table cellpadding="2">
<tr>
<th>Option</th><th>Effect</th>
</tr>
<tr>
<td><tt><span style="white-space:nowrap;">[http://kdesrc-build.kde.org/documentation/cmdline.html#cmdline-pretend --pretend]</span></tt> (Short form <tt><span style="white-space:nowrap;">-p</span></tt>)</td>
<td>This option is like a dry run. kdesrc-build will process the options and its configuration like normal, and run through the build as normal, but instead of downloading or running the build will instead output what kdesrc-build would have done. You should always run with -p before running kdesrc-build to make sure it is doing what you expect.</td>
</tr>
<tr>
<td><tt>[http://kdesrc-build.kde.org/documentation/cmdline.html#cmdline-no-svn --no-svn]</tt> (Alt. form <tt>--no-src</tt>)</td><td>This option skips the source code update step. This is useful if you're running kdesrc-build again soon after the last update and don't want to wait to find out there were no changes.</td>
</tr>
<tr>
<td><tt>[http://kdesrc-build.kde.org/documentation/cmdline.html#cmdline-refresh-build --refresh-build]</tt></td><td>This option causes kdesrc-build to delete the current build information for the given modules and start building them again from scratch. This option takes a lot of time but gives the best chance of a successful build.</td>
</tr>
</table>

Any other non-option arguments on the command line are assumed to be modules to build (and are built in the order provided on the command line). If no modules are specified, all of the modules listed in the ~/.kdesrc-buildrc are built in the order listed in the file.

== Build ==
We're almost there. If you're happy with your settings then it's time to test out kdesrc-build. In theory things are as simple as running kdesrc-build and then coming back later. ;)

<syntaxhighlight lang="bash">
cd ~/kdesrc
./kdesrc-build
</syntaxhighlight>

You may want to test by building qt-copy first however.

<syntaxhighlight lang="bash">
cd ~/kdesrc
./kdesrc-build qt-copy
</syntaxhighlight>

{{tip|If you have the [http://www.gnu.org/software/screen/ GNU screen] program available then you should definitely use it to run kdesrc-build, as you can detach your kdesrc-build session and logout while kdesrc-build is still running.}}

If the build failed (kdesrc-build will error out with a nice bright red error message) then there are several possibilities:

# You are missing a key piece of required software (such as a development library)
# The KDE SC code being compiled is broken in some fashion to where it won't build. This is commonly due to newly committed code that worked on the developer's machine, or occasionally on Mondays (when incompatible changes are permitted to kdelibs).
# kdesrc-build is not setup properly. You may be trying to install to a directory that you have no permissions to access for instance, or you may have specified a system qtdir that does not exist.
# The module may depend on a newer version of qt-copy or kdelibs (or other module). In this case you'll have to run kdesrc-build to update the out-of-date module first.

How do you find out what the error was? The output of the failing command will be in the log directory. By default, all log output is in the {{path|log}} subdirectory of the KDE SC source directory. The log directory is laid out like this: {{path|log/date-run/module/output-file.log}}. To simplify finding the appropriate file, there are a couple of symlinks created:

{{path|log/latest}} always has the debugging output for the last time kdesrc-build was run (--pretend doesn't count toward this)
{{path|log/latest/<module>/error.log}} has the debugging output for the command that caused a module build to fail.

For instance if qt-copy just failed to build you could read the output like this:

<syntaxhighlight lang="bash">
cd ~/kderc
kwrite log/latest/qt-copy/error.log
</syntaxhighlight>

Replace kwrite with your preferred editor. Hopefully the output can guide you to resolving the problem. For instance, if the failure is a cmake output saying you're missing a library, install that library and try again. ;) For link errors you can try running a --refresh-build on the module (or if that doesn't work, required libraries like qt-copy and kdelibs).

If you're stumped by the error you may want to wait a day and try updating again, and hope that the reason for the error has been fixed. You can also try mailing the [http://www.kde.org/mailinglists/ kde-devel] mailing list to see if others know about the problem or have had similar issues.

== Running KDE ==

Assuming you got enough of the modules to build and install to have a working KDE installation, you'll still need to setup your environment correctly to run it. kdesrc-build doesn't help you out here (yet), so you should follow the instructions [[Getting_Started/Using_an_IDE_with_KDE4|here]].

Make sure to use the same paths as the ones you defined in .kdesrc-buildrc: for the KDEDIRS and KDEDIR variable use the setting of the "prefix" option (in the global section). For the QTDIR variable use the setting of the "qtdir" option.

== Keeping KDE up to date ==

Keeping your KDE installation up to date is as simple as running kdesrc-build again. Every kdesrc-build has these phases:

# Update the source code for all modules being built.
# Build and then install all the modules.

Old build directories are not deleted by default, so the build after a small update will not normally take as long as the initial build of a module. This is called "incremental make". However it may be necessary at times to perform a full rebuild due to inconsistencies between the build directory configuation and changes to the source directory. You can use the --refresh-build option to force a full rebuild.

For more information on how to take advantage of kdesrc-build, see the [http://kdesrc-build.kde.org/documentation online documentation] for kdesrc-build, which describes all of the module options and command line options available for kdesrc-build and gives tips on how to perform various useful tasks.

If you have any questions that are not answered please feel free to add them under the Discussion entry for this page and hopefully someone will be able to get the answer.

= See also =
* To browse the KDE Subversion repository, use [http://websvn.kde.org/trunk/KDE WebSVN].
* To browse any of the various KDE projects using git, you can go to [http://projects.kde.org KDE Git Projects] or to [http://gitweb.kde.org KDE Git Web].
* The Nokia Qt toolkit used by KDE can be browsed at [http://qt.gitorious.org/qt Nokia's Qt version on gitorious].

[[Category:Build_KDE]]
[[Category:Tutorial]]

Getting Started/Build/kdesrc-build

2013-01-27T09:32:28Z

Tstaerk: /* Prerequisites */

{{note|It is possible to build KDE 3 using older versions of kdesrc-build, but this is not described here.}}

== Building KDE using the kdesrc-build tool ==

=== Introduction to kdesrc-build ===

[http://kdesrc-build.kde.org/ kdesrc-build] (formerly kdesvn-build) is a tool to allow users and developers to easily download and build the latest versions of the [http://www.kde.org/ KDE Software Compilation] (KDE SC) from the KDE source code repositories. It automates the following tasks and more:

* Performing the initial checkout.
* Handling updates for modules that are already checked out.
* Setting up the build system for the module.
* Performing the build and install.
* Specifying your CMake options or configure flags (so you don't have to remember them every time).
* Logging build errors so you can review them easier for troubleshooting.

It is not the end-all for your troubles building KDE, [[../Troubleshooting|Troubleshooting]] still applies. Many errors that occur using other methods occur here too, you read the log files that are stored for you.

=== Why use kdesrc-build? ===

So why use kdesrc-build? There are several reasons you may like to use it:

# Less manual editing of commands. Instead of having to remember to add the correct options to the cmake command line or configure command, you can setup the options once and then kdesrc-build will use your settings from then on, saving you from wasting time because you forgot to enable a setting.
# Command logging to help debug build failures. kdesrc-build logs all command outputs to a file. This has several advantages:
## When a module fails to build, you already have the error output saved to disk, ready to be viewed and compared with other error messages to aid debugging.
## Quieter output. Even with CMake, the output of Qt or a KDE SC module build can be extensive. kdesrc-build does not show the details of a module build (but will show the progress), instead an overview of the build process is displayed.
# It's just easier. Instead of having to learn how to use the Subversion and git tools, and how to setup a KDE build system, you can specify what modules you want build, where to install them to, and any other options you want and then have kdesrc-build actually do it, even while you're away from the computer or busy doing other things.
# It's easy to step in yourself. kdesrc-build uses a standard source and build directory layout, and calls the same commands you would. So kdesrc-build will not interfere with you performing the build or editing the source yourself if you so choose.

=== Setting up ===

==== Prerequisites ====
kdesrc-build is fairly easy to install and setup, but you also need to have the right software installed to build KDE. The requirements to build KDE are available as follows:

* KDE 4: [[../Requirements|KDE 4 Requirements]]

kdesrc-build requires Perl 5.10 or higher. It is installed by default with most distributions, and is included in the link above. Check your version of Perl with:
<syntaxhighlight lang="text">perl -v</syntaxhighlight>

You will also need [https://github.com/gisle/libwww-perl#readme libwww] (sometimes called LWP), a collection of Perl Internet-related modules, and [http://search.cpan.org/~toddr/XML-Parser/Parser.pm XML::Parser] to support the XML-based KDE Project database. Both of these modules are extremely common and should be available in your distribution's packager manager. For example for SUSE install them with
yast -i perl-libwww-perl

kdesrc-build itself may be packaged on your distribution, which allows you to easily install its dependencies as well. ([http://packages.debian.org/unstable/main/kdesrc-build Debian provides packages] and a Fedora package is pending a fix to the kdesrc-build sources).

{{note|kdesrc-build is developed on a Linux system, but it should work on the various BSD distributions as well (although GNU tools may be required).}}

==== Download and install kdesrc-build ====
Download kdesrc from git like this:
<syntaxhighlight lang="bash">
git clone git://anongit.kde.org/kdesrc-build.git ~/kdesrc
</syntaxhighlight>

==== Setup the configuration ====
Now you should [[Getting Started/Build/kdesrc-build-config|setup your configuration]]. For the most part the defaults in the included kdesrc-buildrc-sample should be sufficient.

<syntaxhighlight lang="bash">
cp ~/kdesrc-build/kdesrc-buildrc-sample ~/.kdesrc-buildrc
</syntaxhighlight>

Now you can start kdesrc-build using the commands
cd
kdesrc-build/kdesrc-build

Now you can edit the configuration file ~/.kdesrc-buildrc

{{tip|Note that the config file's name begins with a leading ., making it a hidden file. You may need to show hidden files in Dolphin or Konqueror to find the configuration file to edit it. Or, you can edit the sample before copying it to ~/.kdesrc-buildrc.}}

Also, make sure that the modules you'll want to build are included. You'll want the following at the least:

* qt-copy, kdesupport, kdelibs, kdepimlibs, kdebase

Modules are built in the order they appear in your ~/.kdesrc-buildrc, so the first module should be qt-copy, kdelibs should be before any other KDE SC module, and so on.

{{note|The sample configuration file does include these modules by default, you won't need to make many changes unless you'd like to add some modules to the build by uncommenting them.}}

You may want to enable the make-install-prefix option if you are installing KDE SC or Qt to a directory that is not in your home directory. make-install-prefix allows you to run su or sudo during the make install process so you can install files as root, or set certain programs to execute with higher permissions (This is required for certain programs to execute properly).

<pre>module kdelibs
make-install-prefix sudo -S # sudo with no stdin
end module

module kdebase
make-install-prefix sudo -S
end module</pre>

If a module you'd like to build isn't already present, simply add

<pre>module <module-name>
end module</pre> at the end of the ~/.kdesrc-buildrc. <module-name> would be whatever the module is called in the software repository (for instance, kdemultimedia).

===== Git-based modules =====

Some KDE projects use the "git" source-control software instead of Subversion (as part of an ongoing migration to git). This includes software like Amarok and Konversation.

To build these modules in kdesrc-build, you just need to add a couple of lines to the module configuration. For example, konversation is developed in the Git repository at [https://projects.kde.org/projects/extragear/network/konversation/repository]. So you would just add a module (you can pick whatever name for the module you like, as long as it's not already used):

<pre>module konversation
repository git://anongit.kde.org/konversation
branch master
end module</pre>

In this case I selected the "master" branch since that is the default git branch.

Now whenever you build konversation, kdesrc-build will use git instead of Subversion.

==== Useful kdesrc-build commands ====
kdesrc-build is driven from the command line, so here's a guide to some of the more useful command line options:

<table cellpadding="2">
<tr>
<th>Option</th><th>Effect</th>
</tr>
<tr>
<td><tt><span style="white-space:nowrap;">[http://kdesrc-build.kde.org/documentation/cmdline.html#cmdline-pretend --pretend]</span></tt> (Short form <tt><span style="white-space:nowrap;">-p</span></tt>)</td>
<td>This option is like a dry run. kdesrc-build will process the options and its configuration like normal, and run through the build as normal, but instead of downloading or running the build will instead output what kdesrc-build would have done. You should always run with -p before running kdesrc-build to make sure it is doing what you expect.</td>
</tr>
<tr>
<td><tt>[http://kdesrc-build.kde.org/documentation/cmdline.html#cmdline-no-svn --no-svn]</tt> (Alt. form <tt>--no-src</tt>)</td><td>This option skips the source code update step. This is useful if you're running kdesrc-build again soon after the last update and don't want to wait to find out there were no changes.</td>
</tr>
<tr>
<td><tt>[http://kdesrc-build.kde.org/documentation/cmdline.html#cmdline-refresh-build --refresh-build]</tt></td><td>This option causes kdesrc-build to delete the current build information for the given modules and start building them again from scratch. This option takes a lot of time but gives the best chance of a successful build.</td>
</tr>
</table>

Any other non-option arguments on the command line are assumed to be modules to build (and are built in the order provided on the command line). If no modules are specified, all of the modules listed in the ~/.kdesrc-buildrc are built in the order listed in the file.

== Build ==
We're almost there. If you're happy with your settings then it's time to test out kdesrc-build. In theory things are as simple as running kdesrc-build and then coming back later. ;)

<syntaxhighlight lang="bash">
cd ~/kdesrc
./kdesrc-build
</syntaxhighlight>

You may want to test by building qt-copy first however.

<syntaxhighlight lang="bash">
cd ~/kdesrc
./kdesrc-build qt-copy
</syntaxhighlight>

{{tip|If you have the [http://www.gnu.org/software/screen/ GNU screen] program available then you should definitely use it to run kdesrc-build, as you can detach your kdesrc-build session and logout while kdesrc-build is still running.}}

If the build failed (kdesrc-build will error out with a nice bright red error message) then there are several possibilities:

# You are missing a key piece of required software (such as a development library)
# The KDE SC code being compiled is broken in some fashion to where it won't build. This is commonly due to newly committed code that worked on the developer's machine, or occasionally on Mondays (when incompatible changes are permitted to kdelibs).
# kdesrc-build is not setup properly. You may be trying to install to a directory that you have no permissions to access for instance, or you may have specified a system qtdir that does not exist.
# The module may depend on a newer version of qt-copy or kdelibs (or other module). In this case you'll have to run kdesrc-build to update the out-of-date module first.

How do you find out what the error was? The output of the failing command will be in the log directory. By default, all log output is in the {{path|log}} subdirectory of the KDE SC source directory. The log directory is laid out like this: {{path|log/date-run/module/output-file.log}}. To simplify finding the appropriate file, there are a couple of symlinks created:

{{path|log/latest}} always has the debugging output for the last time kdesrc-build was run (--pretend doesn't count toward this)
{{path|log/latest/<module>/error.log}} has the debugging output for the command that caused a module build to fail.

For instance if qt-copy just failed to build you could read the output like this:

<syntaxhighlight lang="bash">
cd ~/kderc
kwrite log/latest/qt-copy/error.log
</syntaxhighlight>

Replace kwrite with your preferred editor. Hopefully the output can guide you to resolving the problem. For instance, if the failure is a cmake output saying you're missing a library, install that library and try again. ;) For link errors you can try running a --refresh-build on the module (or if that doesn't work, required libraries like qt-copy and kdelibs).

If you're stumped by the error you may want to wait a day and try updating again, and hope that the reason for the error has been fixed. You can also try mailing the [http://www.kde.org/mailinglists/ kde-devel] mailing list to see if others know about the problem or have had similar issues.

== Running KDE ==

Assuming you got enough of the modules to build and install to have a working KDE installation, you'll still need to setup your environment correctly to run it. kdesrc-build doesn't help you out here (yet), so you should follow the instructions [[Getting_Started/Using_an_IDE_with_KDE4|here]].

Make sure to use the same paths as the ones you defined in .kdesrc-buildrc: for the KDEDIRS and KDEDIR variable use the setting of the "prefix" option (in the global section). For the QTDIR variable use the setting of the "qtdir" option.

== Keeping KDE up to date ==

Keeping your KDE installation up to date is as simple as running kdesrc-build again. Every kdesrc-build has these phases:

# Update the source code for all modules being built.
# Build and then install all the modules.

Old build directories are not deleted by default, so the build after a small update will not normally take as long as the initial build of a module. This is called "incremental make". However it may be necessary at times to perform a full rebuild due to inconsistencies between the build directory configuation and changes to the source directory. You can use the --refresh-build option to force a full rebuild.

For more information on how to take advantage of kdesrc-build, see the [http://kdesrc-build.kde.org/documentation online documentation] for kdesrc-build, which describes all of the module options and command line options available for kdesrc-build and gives tips on how to perform various useful tasks.

If you have any questions that are not answered please feel free to add them under the Discussion entry for this page and hopefully someone will be able to get the answer.

= See also =
* To browse the KDE Subversion repository, use [http://websvn.kde.org/trunk/KDE WebSVN].
* To browse any of the various KDE projects using git, you can go to [http://projects.kde.org KDE Git Projects] or to [http://gitweb.kde.org KDE Git Web].
* The Nokia Qt toolkit used by KDE can be browsed at [http://qt.gitorious.org/qt Nokia's Qt version on gitorious].

[[Category:Build_KDE]]
[[Category:Tutorial]]

Thread:Talk:Installing third party softwares in terminal/Build/kdesrc-build/error message when starting

2013-01-27T09:30:33Z

Tstaerk: New thread: error message when starting

I get
# kdesrc-build/kdesrc-build
Can't locate LWP/UserAgent.pm in @INC (@INC contains: /root/kdesrc-build/modules /root/kdesrc-build/../share/apps/kdesrc-build/modules /usr/lib/perl5/site_perl/5.16.0/x86_64-linux-thread-multi /usr/lib/perl5/site_perl/5.16.0 /usr/lib/perl5/vendor_perl/5.16.0/x86_64-linux-thread-multi /usr/lib/perl5/vendor_perl/5.16.0 /usr/lib/perl5/5.16.0/x86_64-linux-thread-multi /usr/lib/perl5/5.16.0 /usr/lib/perl5/site_perl .) at kdesrc-build/kdesrc-build line 54.
BEGIN failed--compilation aborted at kdesrc-build/kdesrc-build line 54.

Getting Started/Build/kdesrc-build

2013-01-27T09:28:54Z

Tstaerk: /* Setup the configuration */

{{note|It is possible to build KDE 3 using older versions of kdesrc-build, but this is not described here.}}

== Building KDE using the kdesrc-build tool ==

=== Introduction to kdesrc-build ===

[http://kdesrc-build.kde.org/ kdesrc-build] (formerly kdesvn-build) is a tool to allow users and developers to easily download and build the latest versions of the [http://www.kde.org/ KDE Software Compilation] (KDE SC) from the KDE source code repositories. It automates the following tasks and more:

* Performing the initial checkout.
* Handling updates for modules that are already checked out.
* Setting up the build system for the module.
* Performing the build and install.
* Specifying your CMake options or configure flags (so you don't have to remember them every time).
* Logging build errors so you can review them easier for troubleshooting.

It is not the end-all for your troubles building KDE, [[../Troubleshooting|Troubleshooting]] still applies. Many errors that occur using other methods occur here too, you read the log files that are stored for you.

=== Why use kdesrc-build? ===

So why use kdesrc-build? There are several reasons you may like to use it:

# Less manual editing of commands. Instead of having to remember to add the correct options to the cmake command line or configure command, you can setup the options once and then kdesrc-build will use your settings from then on, saving you from wasting time because you forgot to enable a setting.
# Command logging to help debug build failures. kdesrc-build logs all command outputs to a file. This has several advantages:
## When a module fails to build, you already have the error output saved to disk, ready to be viewed and compared with other error messages to aid debugging.
## Quieter output. Even with CMake, the output of Qt or a KDE SC module build can be extensive. kdesrc-build does not show the details of a module build (but will show the progress), instead an overview of the build process is displayed.
# It's just easier. Instead of having to learn how to use the Subversion and git tools, and how to setup a KDE build system, you can specify what modules you want build, where to install them to, and any other options you want and then have kdesrc-build actually do it, even while you're away from the computer or busy doing other things.
# It's easy to step in yourself. kdesrc-build uses a standard source and build directory layout, and calls the same commands you would. So kdesrc-build will not interfere with you performing the build or editing the source yourself if you so choose.

=== Setting up ===

==== Prerequisites ====
kdesrc-build is fairly easy to install and setup, but you also need to have the right software installed to build KDE. The requirements to build KDE are available as follows:

* KDE 4: [[../Requirements|KDE 4 Requirements]]

kdesrc-build requires Perl 5.10 or higher. It is installed by default with most distributions, and is included in the link above. Check your version of Perl with:
<syntaxhighlight lang="text">perl -v</syntaxhighlight>

You will also need [https://github.com/gisle/libwww-perl#readme libwww] (sometimes called LWP), a collection of Perl Internet-related modules, and [http://search.cpan.org/~toddr/XML-Parser/Parser.pm XML::Parser] to support the XML-based KDE Project database. Both of these modules are extremely common and should be available in your distribution's packager manager.

kdesrc-build itself may be packaged on your distribution, which allows you to easily install its dependencies as well. ([http://packages.debian.org/unstable/main/kdesrc-build Debian provides packages] and a Fedora package is pending a fix to the kdesrc-build sources).

{{note|kdesrc-build is developed on a Linux system, but it should work on the various BSD distributions as well (although GNU tools may be required).}}

==== Download and install kdesrc-build ====
Download kdesrc from git like this:
<syntaxhighlight lang="bash">
git clone git://anongit.kde.org/kdesrc-build.git ~/kdesrc
</syntaxhighlight>

==== Setup the configuration ====
Now you should [[Getting Started/Build/kdesrc-build-config|setup your configuration]]. For the most part the defaults in the included kdesrc-buildrc-sample should be sufficient.

<syntaxhighlight lang="bash">
cp ~/kdesrc-build/kdesrc-buildrc-sample ~/.kdesrc-buildrc
</syntaxhighlight>

Now you can start kdesrc-build using the commands
cd
kdesrc-build/kdesrc-build

Now you can edit the configuration file ~/.kdesrc-buildrc

{{tip|Note that the config file's name begins with a leading ., making it a hidden file. You may need to show hidden files in Dolphin or Konqueror to find the configuration file to edit it. Or, you can edit the sample before copying it to ~/.kdesrc-buildrc.}}

Also, make sure that the modules you'll want to build are included. You'll want the following at the least:

* qt-copy, kdesupport, kdelibs, kdepimlibs, kdebase

Modules are built in the order they appear in your ~/.kdesrc-buildrc, so the first module should be qt-copy, kdelibs should be before any other KDE SC module, and so on.

{{note|The sample configuration file does include these modules by default, you won't need to make many changes unless you'd like to add some modules to the build by uncommenting them.}}

You may want to enable the make-install-prefix option if you are installing KDE SC or Qt to a directory that is not in your home directory. make-install-prefix allows you to run su or sudo during the make install process so you can install files as root, or set certain programs to execute with higher permissions (This is required for certain programs to execute properly).

<pre>module kdelibs
make-install-prefix sudo -S # sudo with no stdin
end module

module kdebase
make-install-prefix sudo -S
end module</pre>

If a module you'd like to build isn't already present, simply add

<pre>module <module-name>
end module</pre> at the end of the ~/.kdesrc-buildrc. <module-name> would be whatever the module is called in the software repository (for instance, kdemultimedia).

===== Git-based modules =====

Some KDE projects use the "git" source-control software instead of Subversion (as part of an ongoing migration to git). This includes software like Amarok and Konversation.

To build these modules in kdesrc-build, you just need to add a couple of lines to the module configuration. For example, konversation is developed in the Git repository at [https://projects.kde.org/projects/extragear/network/konversation/repository]. So you would just add a module (you can pick whatever name for the module you like, as long as it's not already used):

<pre>module konversation
repository git://anongit.kde.org/konversation
branch master
end module</pre>

In this case I selected the "master" branch since that is the default git branch.

Now whenever you build konversation, kdesrc-build will use git instead of Subversion.

==== Useful kdesrc-build commands ====
kdesrc-build is driven from the command line, so here's a guide to some of the more useful command line options:

<table cellpadding="2">
<tr>
<th>Option</th><th>Effect</th>
</tr>
<tr>
<td><tt><span style="white-space:nowrap;">[http://kdesrc-build.kde.org/documentation/cmdline.html#cmdline-pretend --pretend]</span></tt> (Short form <tt><span style="white-space:nowrap;">-p</span></tt>)</td>
<td>This option is like a dry run. kdesrc-build will process the options and its configuration like normal, and run through the build as normal, but instead of downloading or running the build will instead output what kdesrc-build would have done. You should always run with -p before running kdesrc-build to make sure it is doing what you expect.</td>
</tr>
<tr>
<td><tt>[http://kdesrc-build.kde.org/documentation/cmdline.html#cmdline-no-svn --no-svn]</tt> (Alt. form <tt>--no-src</tt>)</td><td>This option skips the source code update step. This is useful if you're running kdesrc-build again soon after the last update and don't want to wait to find out there were no changes.</td>
</tr>
<tr>
<td><tt>[http://kdesrc-build.kde.org/documentation/cmdline.html#cmdline-refresh-build --refresh-build]</tt></td><td>This option causes kdesrc-build to delete the current build information for the given modules and start building them again from scratch. This option takes a lot of time but gives the best chance of a successful build.</td>
</tr>
</table>

Any other non-option arguments on the command line are assumed to be modules to build (and are built in the order provided on the command line). If no modules are specified, all of the modules listed in the ~/.kdesrc-buildrc are built in the order listed in the file.

== Build ==
We're almost there. If you're happy with your settings then it's time to test out kdesrc-build. In theory things are as simple as running kdesrc-build and then coming back later. ;)

<syntaxhighlight lang="bash">
cd ~/kdesrc
./kdesrc-build
</syntaxhighlight>

You may want to test by building qt-copy first however.

<syntaxhighlight lang="bash">
cd ~/kdesrc
./kdesrc-build qt-copy
</syntaxhighlight>

{{tip|If you have the [http://www.gnu.org/software/screen/ GNU screen] program available then you should definitely use it to run kdesrc-build, as you can detach your kdesrc-build session and logout while kdesrc-build is still running.}}

If the build failed (kdesrc-build will error out with a nice bright red error message) then there are several possibilities:

# You are missing a key piece of required software (such as a development library)
# The KDE SC code being compiled is broken in some fashion to where it won't build. This is commonly due to newly committed code that worked on the developer's machine, or occasionally on Mondays (when incompatible changes are permitted to kdelibs).
# kdesrc-build is not setup properly. You may be trying to install to a directory that you have no permissions to access for instance, or you may have specified a system qtdir that does not exist.
# The module may depend on a newer version of qt-copy or kdelibs (or other module). In this case you'll have to run kdesrc-build to update the out-of-date module first.

How do you find out what the error was? The output of the failing command will be in the log directory. By default, all log output is in the {{path|log}} subdirectory of the KDE SC source directory. The log directory is laid out like this: {{path|log/date-run/module/output-file.log}}. To simplify finding the appropriate file, there are a couple of symlinks created:

{{path|log/latest}} always has the debugging output for the last time kdesrc-build was run (--pretend doesn't count toward this)
{{path|log/latest/<module>/error.log}} has the debugging output for the command that caused a module build to fail.

For instance if qt-copy just failed to build you could read the output like this:

<syntaxhighlight lang="bash">
cd ~/kderc
kwrite log/latest/qt-copy/error.log
</syntaxhighlight>

Replace kwrite with your preferred editor. Hopefully the output can guide you to resolving the problem. For instance, if the failure is a cmake output saying you're missing a library, install that library and try again. ;) For link errors you can try running a --refresh-build on the module (or if that doesn't work, required libraries like qt-copy and kdelibs).

If you're stumped by the error you may want to wait a day and try updating again, and hope that the reason for the error has been fixed. You can also try mailing the [http://www.kde.org/mailinglists/ kde-devel] mailing list to see if others know about the problem or have had similar issues.

== Running KDE ==

Assuming you got enough of the modules to build and install to have a working KDE installation, you'll still need to setup your environment correctly to run it. kdesrc-build doesn't help you out here (yet), so you should follow the instructions [[Getting_Started/Using_an_IDE_with_KDE4|here]].

Make sure to use the same paths as the ones you defined in .kdesrc-buildrc: for the KDEDIRS and KDEDIR variable use the setting of the "prefix" option (in the global section). For the QTDIR variable use the setting of the "qtdir" option.

== Keeping KDE up to date ==

Keeping your KDE installation up to date is as simple as running kdesrc-build again. Every kdesrc-build has these phases:

# Update the source code for all modules being built.
# Build and then install all the modules.

Old build directories are not deleted by default, so the build after a small update will not normally take as long as the initial build of a module. This is called "incremental make". However it may be necessary at times to perform a full rebuild due to inconsistencies between the build directory configuation and changes to the source directory. You can use the --refresh-build option to force a full rebuild.

For more information on how to take advantage of kdesrc-build, see the [http://kdesrc-build.kde.org/documentation online documentation] for kdesrc-build, which describes all of the module options and command line options available for kdesrc-build and gives tips on how to perform various useful tasks.

If you have any questions that are not answered please feel free to add them under the Discussion entry for this page and hopefully someone will be able to get the answer.

= See also =
* To browse the KDE Subversion repository, use [http://websvn.kde.org/trunk/KDE WebSVN].
* To browse any of the various KDE projects using git, you can go to [http://projects.kde.org KDE Git Projects] or to [http://gitweb.kde.org KDE Git Web].
* The Nokia Qt toolkit used by KDE can be browsed at [http://qt.gitorious.org/qt Nokia's Qt version on gitorious].

[[Category:Build_KDE]]
[[Category:Tutorial]]

Getting Started/Build/kdesrc-build

2013-01-27T09:27:30Z

Tstaerk: /* Setup the configuration */

{{note|It is possible to build KDE 3 using older versions of kdesrc-build, but this is not described here.}}

== Building KDE using the kdesrc-build tool ==

=== Introduction to kdesrc-build ===

[http://kdesrc-build.kde.org/ kdesrc-build] (formerly kdesvn-build) is a tool to allow users and developers to easily download and build the latest versions of the [http://www.kde.org/ KDE Software Compilation] (KDE SC) from the KDE source code repositories. It automates the following tasks and more:

* Performing the initial checkout.
* Handling updates for modules that are already checked out.
* Setting up the build system for the module.
* Performing the build and install.
* Specifying your CMake options or configure flags (so you don't have to remember them every time).
* Logging build errors so you can review them easier for troubleshooting.

It is not the end-all for your troubles building KDE, [[../Troubleshooting|Troubleshooting]] still applies. Many errors that occur using other methods occur here too, you read the log files that are stored for you.

=== Why use kdesrc-build? ===

So why use kdesrc-build? There are several reasons you may like to use it:

# Less manual editing of commands. Instead of having to remember to add the correct options to the cmake command line or configure command, you can setup the options once and then kdesrc-build will use your settings from then on, saving you from wasting time because you forgot to enable a setting.
# Command logging to help debug build failures. kdesrc-build logs all command outputs to a file. This has several advantages:
## When a module fails to build, you already have the error output saved to disk, ready to be viewed and compared with other error messages to aid debugging.
## Quieter output. Even with CMake, the output of Qt or a KDE SC module build can be extensive. kdesrc-build does not show the details of a module build (but will show the progress), instead an overview of the build process is displayed.
# It's just easier. Instead of having to learn how to use the Subversion and git tools, and how to setup a KDE build system, you can specify what modules you want build, where to install them to, and any other options you want and then have kdesrc-build actually do it, even while you're away from the computer or busy doing other things.
# It's easy to step in yourself. kdesrc-build uses a standard source and build directory layout, and calls the same commands you would. So kdesrc-build will not interfere with you performing the build or editing the source yourself if you so choose.

=== Setting up ===

==== Prerequisites ====
kdesrc-build is fairly easy to install and setup, but you also need to have the right software installed to build KDE. The requirements to build KDE are available as follows:

* KDE 4: [[../Requirements|KDE 4 Requirements]]

kdesrc-build requires Perl 5.10 or higher. It is installed by default with most distributions, and is included in the link above. Check your version of Perl with:
<syntaxhighlight lang="text">perl -v</syntaxhighlight>

You will also need [https://github.com/gisle/libwww-perl#readme libwww] (sometimes called LWP), a collection of Perl Internet-related modules, and [http://search.cpan.org/~toddr/XML-Parser/Parser.pm XML::Parser] to support the XML-based KDE Project database. Both of these modules are extremely common and should be available in your distribution's packager manager.

kdesrc-build itself may be packaged on your distribution, which allows you to easily install its dependencies as well. ([http://packages.debian.org/unstable/main/kdesrc-build Debian provides packages] and a Fedora package is pending a fix to the kdesrc-build sources).

{{note|kdesrc-build is developed on a Linux system, but it should work on the various BSD distributions as well (although GNU tools may be required).}}

==== Download and install kdesrc-build ====
Download kdesrc from git like this:
<syntaxhighlight lang="bash">
git clone git://anongit.kde.org/kdesrc-build.git ~/kdesrc
</syntaxhighlight>

==== Setup the configuration ====
Now you should [[Getting Started/Build/kdesrc-build-config|setup your configuration]]. For the most part the defaults in the included kdesrc-buildrc-sample should be sufficient.

<syntaxhighlight lang="bash">
cp ~/kdesrc-build/kdesrc-buildrc-sample ~/.kdesrc-buildrc
</syntaxhighlight>

Now you can start kdesrc-build using the commands
cd
./kdesrc-build

Now you can edit the configuration file ~/.kdesrc-buildrc

{{tip|Note that the config file's name begins with a leading ., making it a hidden file. You may need to show hidden files in Dolphin or Konqueror to find the configuration file to edit it. Or, you can edit the sample before copying it to ~/.kdesrc-buildrc.}}

Also, make sure that the modules you'll want to build are included. You'll want the following at the least:

* qt-copy, kdesupport, kdelibs, kdepimlibs, kdebase

Modules are built in the order they appear in your ~/.kdesrc-buildrc, so the first module should be qt-copy, kdelibs should be before any other KDE SC module, and so on.

{{note|The sample configuration file does include these modules by default, you won't need to make many changes unless you'd like to add some modules to the build by uncommenting them.}}

You may want to enable the make-install-prefix option if you are installing KDE SC or Qt to a directory that is not in your home directory. make-install-prefix allows you to run su or sudo during the make install process so you can install files as root, or set certain programs to execute with higher permissions (This is required for certain programs to execute properly).

<pre>module kdelibs
make-install-prefix sudo -S # sudo with no stdin
end module

module kdebase
make-install-prefix sudo -S
end module</pre>

If a module you'd like to build isn't already present, simply add

<pre>module <module-name>
end module</pre> at the end of the ~/.kdesrc-buildrc. <module-name> would be whatever the module is called in the software repository (for instance, kdemultimedia).

===== Git-based modules =====

Some KDE projects use the "git" source-control software instead of Subversion (as part of an ongoing migration to git). This includes software like Amarok and Konversation.

To build these modules in kdesrc-build, you just need to add a couple of lines to the module configuration. For example, konversation is developed in the Git repository at [https://projects.kde.org/projects/extragear/network/konversation/repository]. So you would just add a module (you can pick whatever name for the module you like, as long as it's not already used):

<pre>module konversation
repository git://anongit.kde.org/konversation
branch master
end module</pre>

In this case I selected the "master" branch since that is the default git branch.

Now whenever you build konversation, kdesrc-build will use git instead of Subversion.

==== Useful kdesrc-build commands ====
kdesrc-build is driven from the command line, so here's a guide to some of the more useful command line options:

<table cellpadding="2">
<tr>
<th>Option</th><th>Effect</th>
</tr>
<tr>
<td><tt><span style="white-space:nowrap;">[http://kdesrc-build.kde.org/documentation/cmdline.html#cmdline-pretend --pretend]</span></tt> (Short form <tt><span style="white-space:nowrap;">-p</span></tt>)</td>
<td>This option is like a dry run. kdesrc-build will process the options and its configuration like normal, and run through the build as normal, but instead of downloading or running the build will instead output what kdesrc-build would have done. You should always run with -p before running kdesrc-build to make sure it is doing what you expect.</td>
</tr>
<tr>
<td><tt>[http://kdesrc-build.kde.org/documentation/cmdline.html#cmdline-no-svn --no-svn]</tt> (Alt. form <tt>--no-src</tt>)</td><td>This option skips the source code update step. This is useful if you're running kdesrc-build again soon after the last update and don't want to wait to find out there were no changes.</td>
</tr>
<tr>
<td><tt>[http://kdesrc-build.kde.org/documentation/cmdline.html#cmdline-refresh-build --refresh-build]</tt></td><td>This option causes kdesrc-build to delete the current build information for the given modules and start building them again from scratch. This option takes a lot of time but gives the best chance of a successful build.</td>
</tr>
</table>

Any other non-option arguments on the command line are assumed to be modules to build (and are built in the order provided on the command line). If no modules are specified, all of the modules listed in the ~/.kdesrc-buildrc are built in the order listed in the file.

== Build ==
We're almost there. If you're happy with your settings then it's time to test out kdesrc-build. In theory things are as simple as running kdesrc-build and then coming back later. ;)

<syntaxhighlight lang="bash">
cd ~/kdesrc
./kdesrc-build
</syntaxhighlight>

You may want to test by building qt-copy first however.

<syntaxhighlight lang="bash">
cd ~/kdesrc
./kdesrc-build qt-copy
</syntaxhighlight>

{{tip|If you have the [http://www.gnu.org/software/screen/ GNU screen] program available then you should definitely use it to run kdesrc-build, as you can detach your kdesrc-build session and logout while kdesrc-build is still running.}}

If the build failed (kdesrc-build will error out with a nice bright red error message) then there are several possibilities:

# You are missing a key piece of required software (such as a development library)
# The KDE SC code being compiled is broken in some fashion to where it won't build. This is commonly due to newly committed code that worked on the developer's machine, or occasionally on Mondays (when incompatible changes are permitted to kdelibs).
# kdesrc-build is not setup properly. You may be trying to install to a directory that you have no permissions to access for instance, or you may have specified a system qtdir that does not exist.
# The module may depend on a newer version of qt-copy or kdelibs (or other module). In this case you'll have to run kdesrc-build to update the out-of-date module first.

How do you find out what the error was? The output of the failing command will be in the log directory. By default, all log output is in the {{path|log}} subdirectory of the KDE SC source directory. The log directory is laid out like this: {{path|log/date-run/module/output-file.log}}. To simplify finding the appropriate file, there are a couple of symlinks created:

{{path|log/latest}} always has the debugging output for the last time kdesrc-build was run (--pretend doesn't count toward this)
{{path|log/latest/<module>/error.log}} has the debugging output for the command that caused a module build to fail.

For instance if qt-copy just failed to build you could read the output like this:

<syntaxhighlight lang="bash">
cd ~/kderc
kwrite log/latest/qt-copy/error.log
</syntaxhighlight>

Replace kwrite with your preferred editor. Hopefully the output can guide you to resolving the problem. For instance, if the failure is a cmake output saying you're missing a library, install that library and try again. ;) For link errors you can try running a --refresh-build on the module (or if that doesn't work, required libraries like qt-copy and kdelibs).

If you're stumped by the error you may want to wait a day and try updating again, and hope that the reason for the error has been fixed. You can also try mailing the [http://www.kde.org/mailinglists/ kde-devel] mailing list to see if others know about the problem or have had similar issues.

== Running KDE ==

Assuming you got enough of the modules to build and install to have a working KDE installation, you'll still need to setup your environment correctly to run it. kdesrc-build doesn't help you out here (yet), so you should follow the instructions [[Getting_Started/Using_an_IDE_with_KDE4|here]].

Make sure to use the same paths as the ones you defined in .kdesrc-buildrc: for the KDEDIRS and KDEDIR variable use the setting of the "prefix" option (in the global section). For the QTDIR variable use the setting of the "qtdir" option.

== Keeping KDE up to date ==

Keeping your KDE installation up to date is as simple as running kdesrc-build again. Every kdesrc-build has these phases:

# Update the source code for all modules being built.
# Build and then install all the modules.

Old build directories are not deleted by default, so the build after a small update will not normally take as long as the initial build of a module. This is called "incremental make". However it may be necessary at times to perform a full rebuild due to inconsistencies between the build directory configuation and changes to the source directory. You can use the --refresh-build option to force a full rebuild.

For more information on how to take advantage of kdesrc-build, see the [http://kdesrc-build.kde.org/documentation online documentation] for kdesrc-build, which describes all of the module options and command line options available for kdesrc-build and gives tips on how to perform various useful tasks.

If you have any questions that are not answered please feel free to add them under the Discussion entry for this page and hopefully someone will be able to get the answer.

= See also =
* To browse the KDE Subversion repository, use [http://websvn.kde.org/trunk/KDE WebSVN].
* To browse any of the various KDE projects using git, you can go to [http://projects.kde.org KDE Git Projects] or to [http://gitweb.kde.org KDE Git Web].
* The Nokia Qt toolkit used by KDE can be browsed at [http://qt.gitorious.org/qt Nokia's Qt version on gitorious].

[[Category:Build_KDE]]
[[Category:Tutorial]]

Getting Started/Build/kdesrc-build

2013-01-27T09:25:55Z

Tstaerk: the "download page" just says "get it from git"

{{note|It is possible to build KDE 3 using older versions of kdesrc-build, but this is not described here.}}

== Building KDE using the kdesrc-build tool ==

=== Introduction to kdesrc-build ===

[http://kdesrc-build.kde.org/ kdesrc-build] (formerly kdesvn-build) is a tool to allow users and developers to easily download and build the latest versions of the [http://www.kde.org/ KDE Software Compilation] (KDE SC) from the KDE source code repositories. It automates the following tasks and more:

* Performing the initial checkout.
* Handling updates for modules that are already checked out.
* Setting up the build system for the module.
* Performing the build and install.
* Specifying your CMake options or configure flags (so you don't have to remember them every time).
* Logging build errors so you can review them easier for troubleshooting.

It is not the end-all for your troubles building KDE, [[../Troubleshooting|Troubleshooting]] still applies. Many errors that occur using other methods occur here too, you read the log files that are stored for you.

=== Why use kdesrc-build? ===

So why use kdesrc-build? There are several reasons you may like to use it:

# Less manual editing of commands. Instead of having to remember to add the correct options to the cmake command line or configure command, you can setup the options once and then kdesrc-build will use your settings from then on, saving you from wasting time because you forgot to enable a setting.
# Command logging to help debug build failures. kdesrc-build logs all command outputs to a file. This has several advantages:
## When a module fails to build, you already have the error output saved to disk, ready to be viewed and compared with other error messages to aid debugging.
## Quieter output. Even with CMake, the output of Qt or a KDE SC module build can be extensive. kdesrc-build does not show the details of a module build (but will show the progress), instead an overview of the build process is displayed.
# It's just easier. Instead of having to learn how to use the Subversion and git tools, and how to setup a KDE build system, you can specify what modules you want build, where to install them to, and any other options you want and then have kdesrc-build actually do it, even while you're away from the computer or busy doing other things.
# It's easy to step in yourself. kdesrc-build uses a standard source and build directory layout, and calls the same commands you would. So kdesrc-build will not interfere with you performing the build or editing the source yourself if you so choose.

=== Setting up ===

==== Prerequisites ====
kdesrc-build is fairly easy to install and setup, but you also need to have the right software installed to build KDE. The requirements to build KDE are available as follows:

* KDE 4: [[../Requirements|KDE 4 Requirements]]

kdesrc-build requires Perl 5.10 or higher. It is installed by default with most distributions, and is included in the link above. Check your version of Perl with:
<syntaxhighlight lang="text">perl -v</syntaxhighlight>

You will also need [https://github.com/gisle/libwww-perl#readme libwww] (sometimes called LWP), a collection of Perl Internet-related modules, and [http://search.cpan.org/~toddr/XML-Parser/Parser.pm XML::Parser] to support the XML-based KDE Project database. Both of these modules are extremely common and should be available in your distribution's packager manager.

kdesrc-build itself may be packaged on your distribution, which allows you to easily install its dependencies as well. ([http://packages.debian.org/unstable/main/kdesrc-build Debian provides packages] and a Fedora package is pending a fix to the kdesrc-build sources).

{{note|kdesrc-build is developed on a Linux system, but it should work on the various BSD distributions as well (although GNU tools may be required).}}

==== Download and install kdesrc-build ====
Download kdesrc from git like this:
<syntaxhighlight lang="bash">
git clone git://anongit.kde.org/kdesrc-build.git ~/kdesrc
</syntaxhighlight>

==== Setup the configuration ====
Now you should [[Getting Started/Build/kdesrc-build-config|setup your configuration]]. For the most part the defaults in the included kdesrc-buildrc-sample should be sufficient.

<syntaxhighlight lang="bash">
cp ~/kdesrc/kdesrc-build-1.14.1/kdesrc-buildrc-sample ~/.kdesrc-buildrc
</syntaxhighlight>

Now you can start kdesrc-build using the commands
cd
./kdesrc-build

Now you can edit the configuration file ~/.kdesrc-buildrc

{{tip|Note that the config file's name begins with a leading ., making it a hidden file. You may need to show hidden files in Dolphin or Konqueror to find the configuration file to edit it. Or, you can edit the sample before copying it to ~/.kdesrc-buildrc.}}

Also, make sure that the modules you'll want to build are included. You'll want the following at the least:

* qt-copy, kdesupport, kdelibs, kdepimlibs, kdebase

Modules are built in the order they appear in your ~/.kdesrc-buildrc, so the first module should be qt-copy, kdelibs should be before any other KDE SC module, and so on.

{{note|The sample configuration file does include these modules by default, you won't need to make many changes unless you'd like to add some modules to the build by uncommenting them.}}

You may want to enable the make-install-prefix option if you are installing KDE SC or Qt to a directory that is not in your home directory. make-install-prefix allows you to run su or sudo during the make install process so you can install files as root, or set certain programs to execute with higher permissions (This is required for certain programs to execute properly).

<pre>module kdelibs
make-install-prefix sudo -S # sudo with no stdin
end module

module kdebase
make-install-prefix sudo -S
end module</pre>

If a module you'd like to build isn't already present, simply add

<pre>module <module-name>
end module</pre> at the end of the ~/.kdesrc-buildrc. <module-name> would be whatever the module is called in the software repository (for instance, kdemultimedia).

===== Git-based modules =====

Some KDE projects use the "git" source-control software instead of Subversion (as part of an ongoing migration to git). This includes software like Amarok and Konversation.

To build these modules in kdesrc-build, you just need to add a couple of lines to the module configuration. For example, konversation is developed in the Git repository at [https://projects.kde.org/projects/extragear/network/konversation/repository]. So you would just add a module (you can pick whatever name for the module you like, as long as it's not already used):

<pre>module konversation
repository git://anongit.kde.org/konversation
branch master
end module</pre>

In this case I selected the "master" branch since that is the default git branch.

Now whenever you build konversation, kdesrc-build will use git instead of Subversion.

==== Useful kdesrc-build commands ====
kdesrc-build is driven from the command line, so here's a guide to some of the more useful command line options:

<table cellpadding="2">
<tr>
<th>Option</th><th>Effect</th>
</tr>
<tr>
<td><tt><span style="white-space:nowrap;">[http://kdesrc-build.kde.org/documentation/cmdline.html#cmdline-pretend --pretend]</span></tt> (Short form <tt><span style="white-space:nowrap;">-p</span></tt>)</td>
<td>This option is like a dry run. kdesrc-build will process the options and its configuration like normal, and run through the build as normal, but instead of downloading or running the build will instead output what kdesrc-build would have done. You should always run with -p before running kdesrc-build to make sure it is doing what you expect.</td>
</tr>
<tr>
<td><tt>[http://kdesrc-build.kde.org/documentation/cmdline.html#cmdline-no-svn --no-svn]</tt> (Alt. form <tt>--no-src</tt>)</td><td>This option skips the source code update step. This is useful if you're running kdesrc-build again soon after the last update and don't want to wait to find out there were no changes.</td>
</tr>
<tr>
<td><tt>[http://kdesrc-build.kde.org/documentation/cmdline.html#cmdline-refresh-build --refresh-build]</tt></td><td>This option causes kdesrc-build to delete the current build information for the given modules and start building them again from scratch. This option takes a lot of time but gives the best chance of a successful build.</td>
</tr>
</table>

Any other non-option arguments on the command line are assumed to be modules to build (and are built in the order provided on the command line). If no modules are specified, all of the modules listed in the ~/.kdesrc-buildrc are built in the order listed in the file.

== Build ==
We're almost there. If you're happy with your settings then it's time to test out kdesrc-build. In theory things are as simple as running kdesrc-build and then coming back later. ;)

<syntaxhighlight lang="bash">
cd ~/kdesrc
./kdesrc-build
</syntaxhighlight>

You may want to test by building qt-copy first however.

<syntaxhighlight lang="bash">
cd ~/kdesrc
./kdesrc-build qt-copy
</syntaxhighlight>

{{tip|If you have the [http://www.gnu.org/software/screen/ GNU screen] program available then you should definitely use it to run kdesrc-build, as you can detach your kdesrc-build session and logout while kdesrc-build is still running.}}

If the build failed (kdesrc-build will error out with a nice bright red error message) then there are several possibilities:

# You are missing a key piece of required software (such as a development library)
# The KDE SC code being compiled is broken in some fashion to where it won't build. This is commonly due to newly committed code that worked on the developer's machine, or occasionally on Mondays (when incompatible changes are permitted to kdelibs).
# kdesrc-build is not setup properly. You may be trying to install to a directory that you have no permissions to access for instance, or you may have specified a system qtdir that does not exist.
# The module may depend on a newer version of qt-copy or kdelibs (or other module). In this case you'll have to run kdesrc-build to update the out-of-date module first.

How do you find out what the error was? The output of the failing command will be in the log directory. By default, all log output is in the {{path|log}} subdirectory of the KDE SC source directory. The log directory is laid out like this: {{path|log/date-run/module/output-file.log}}. To simplify finding the appropriate file, there are a couple of symlinks created:

{{path|log/latest}} always has the debugging output for the last time kdesrc-build was run (--pretend doesn't count toward this)
{{path|log/latest/<module>/error.log}} has the debugging output for the command that caused a module build to fail.

For instance if qt-copy just failed to build you could read the output like this:

<syntaxhighlight lang="bash">
cd ~/kderc
kwrite log/latest/qt-copy/error.log
</syntaxhighlight>

Replace kwrite with your preferred editor. Hopefully the output can guide you to resolving the problem. For instance, if the failure is a cmake output saying you're missing a library, install that library and try again. ;) For link errors you can try running a --refresh-build on the module (or if that doesn't work, required libraries like qt-copy and kdelibs).

If you're stumped by the error you may want to wait a day and try updating again, and hope that the reason for the error has been fixed. You can also try mailing the [http://www.kde.org/mailinglists/ kde-devel] mailing list to see if others know about the problem or have had similar issues.

== Running KDE ==

Assuming you got enough of the modules to build and install to have a working KDE installation, you'll still need to setup your environment correctly to run it. kdesrc-build doesn't help you out here (yet), so you should follow the instructions [[Getting_Started/Using_an_IDE_with_KDE4|here]].

Make sure to use the same paths as the ones you defined in .kdesrc-buildrc: for the KDEDIRS and KDEDIR variable use the setting of the "prefix" option (in the global section). For the QTDIR variable use the setting of the "qtdir" option.

== Keeping KDE up to date ==

Keeping your KDE installation up to date is as simple as running kdesrc-build again. Every kdesrc-build has these phases:

# Update the source code for all modules being built.
# Build and then install all the modules.

Old build directories are not deleted by default, so the build after a small update will not normally take as long as the initial build of a module. This is called "incremental make". However it may be necessary at times to perform a full rebuild due to inconsistencies between the build directory configuation and changes to the source directory. You can use the --refresh-build option to force a full rebuild.

For more information on how to take advantage of kdesrc-build, see the [http://kdesrc-build.kde.org/documentation online documentation] for kdesrc-build, which describes all of the module options and command line options available for kdesrc-build and gives tips on how to perform various useful tasks.

If you have any questions that are not answered please feel free to add them under the Discussion entry for this page and hopefully someone will be able to get the answer.

= See also =
* To browse the KDE Subversion repository, use [http://websvn.kde.org/trunk/KDE WebSVN].
* To browse any of the various KDE projects using git, you can go to [http://projects.kde.org KDE Git Projects] or to [http://gitweb.kde.org KDE Git Web].
* The Nokia Qt toolkit used by KDE can be browsed at [http://qt.gitorious.org/qt Nokia's Qt version on gitorious].

[[Category:Build_KDE]]
[[Category:Tutorial]]

Development/Tutorials/Using Qt Creator

2013-01-27T08:47:47Z

Tstaerk: If the checkout fails with the message "remote host hung up unexpectedly" do a checkout from konsole. You may have to accept git.kde.org's fingerprint

<languages />
<translate>

__TOC__


QtCreator is an IDE from Nokia for Qt. It contains QtDesigner for UI design. This article describes:
* why to use Qt Creator
* how to create a new application
* how to load an existing application

== Why use Qt Creator == 


{|align="right"
|[[image:Snapshot-qtcreator.png|right|thumb|200px|KDE4's ktimetracker loaded as QtCreator project]]
|}
To create your C++ applications you can use any text editor. But life will be much easier if you gain QtCreator's features. That means
* you can get your source code saved, built and run with one click
* you get code-completion
* you can find all places in your source code where you call a function (e.g. "where do I call refresh()")
* you can go back to a more recent cursor position with your editor, even if this is in another file
* you can checkout and commit to Subversion or Git repositories without leaving your workflow

== Creating a new program == 


Here is a short example of how you can create a "hello world" application. For more information read the [http://qt.nokia.com/doc/designer-manual.html user documentation].


;Step 0:
Call QtCreator
<syntaxhighlight lang="bash">
qtcreator
</syntaxhighlight>
Then select New File or Project -> Qt C++ Project -> Qt Gui Application -> name = helloworld -> Next -> Next -> Finish


;Step 1:
Select Edit -> Forms -> mainwindow.ui. Add the widgets you want by drag-and-drop:


[[File:Designer-step1.png|200px]]


;Step 2:
Select the mainwindow. This is the one un-intuitive step. To lay out the objects in the mainwindow, you do not select the objects in the mainwindow, but the mainwindow itself.


[[File:Designer-step2.png|200px]]


;Step 3:
Select Form -> Lay Out in a <u>G</u>rid


[[File:Designer-step3.png|200px]]


;Result:
You get a decent look, and if you resize the window, the widgets resize as well.


[[File:Designer-result.png|200px]]

=== Using KDE libraries === 


To use KDE classes like KMessageBox, you need to tell QtCreator to use the KDE libraries when building. Go to your home directory, change into ''yourproject'' and modify ''yourproject.pro''. Add the line
<syntaxhighlight lang="make">
LIBS += -lkdeui
</syntaxhighlight>
Then you can start using KDE classes in your code.

=== Adding a toolbar === 


To add a toolbar, right-click on the UI and choose "Add Toolbar". Then you can set icons and text in your mainwindow's constructor with code like this:
<syntaxhighlight lang="cpp-qt">
ui->toolBar->addAction(QIcon("/usr/share/icons/oxygen/22x22/apps/ktip.png"),"hello world");
</syntaxhighlight>
[[Development/Tutorials/Using_Qt_Designer|More Info...]]

== Load an existing project == 


This describes how to use QtCreator to integrate existing KDE 4 applications. It has been tested with QtCreator 1.2.80 and SUSE Linux 11.1 but should work same or similar with every combination. As an example KDE application we use [http://userbase.kde.org/ktimetracker ktimetracker] from the kdepim module, other applications should work likewise.


You can either work with code on your disk or have QtCreator do the repository checkout.

=== use code from your disk === 


* import the CMakeLists.txt file (File -> Open -> kdepim/CMakeLists.txt)
* as build directory choose kdepim
* you will automatically come to a screen where you can run CMake
* continue with the step "Run cmake"

=== have QtCreator do the git checkout === 


* choose File -> New File or Project -> Project from Version Control -> Git Repository Clone.
* enter a Git URL like git@git.kde.org:/kdepim
* accept kdepim as checkout directory
* type finish, see how the checkout starts
;Note: If the checkout fails with the message "remote host hung up unexpectedly" do a checkout from konsole. You may have to accept git.kde.org's fingerprint.
* you will automatically come to a screen where you can run CMake
* continue with the step "Run cmake"

=== have QtCreator do the subversion checkout === 


* choose File -> New File or Project -> Version Control -> Subversion Checkout.
* enter a Subversion URL like svn://anonsvn.kde.org/home/kde/trunk/KDE/kdepim
* enter a checkout directory, i.e. the local directory where the code will be checked-out to
* type finish, see how the checkout starts
* you will automatically come to a screen where you can run CMake
* continue with the step "Run cmake"

=== Run cmake === 


* enter arguments for CMake like
<syntaxhighlight lang="bash">
/root/kdepim -DCMAKE_INSTALL_PREFIX=/usr/local -DLIB_SUFFIX=64 -DCMAKE_BUILD_TYPE=debugfull
</syntaxhighlight>
<tt>DLIB_SUFFIX=64</tt> means that you want to install your libraries into directories named <tt>lib64</tt>, not <tt>lib</tt>. ''/root/kdepim'' is where your source code is.
* click "Run cmake"
* note: a .cbp file is created containing many information about the build
* click "Finish"

=== Build it === 


* configure QtCreator to build only ktimetracker:
Projects -> Active run configuration=ktimetracker -> build settings -> build steps -> make -> show details -> activate ktimetracker.
* configure QtCreator to use 8 logical processors:
Projects -> Active run configuration=ktimetracker -> build settings -> build steps -> make -> show details -> addtional Arguments = -j8
* choose Build -> Build All

== See also == 


* [[Development/Tutorials/Using Qt Designer]]
* [[Getting_Started/Using_an_IDE_with_KDE4#QtCreator]]
</translate>
[[Category:KDE4]]

Development/Tutorials/Using Qt Creator

2013-01-27T08:37:30Z

Tstaerk:

<languages />
<translate>

__TOC__


QtCreator is an IDE from Nokia for Qt. It contains QtDesigner for UI design. This article describes:
* why to use Qt Creator
* how to create a new application
* how to load an existing application

== Why use Qt Creator == 


{|align="right"
|[[image:Snapshot-qtcreator.png|right|thumb|200px|KDE4's ktimetracker loaded as QtCreator project]]
|}
To create your C++ applications you can use any text editor. But life will be much easier if you gain QtCreator's features. That means
* you can get your source code saved, built and run with one click
* you get code-completion
* you can find all places in your source code where you call a function (e.g. "where do I call refresh()")
* you can go back to a more recent cursor position with your editor, even if this is in another file
* you can checkout and commit to Subversion or Git repositories without leaving your workflow

== Creating a new program == 


Here is a short example of how you can create a "hello world" application. For more information read the [http://qt.nokia.com/doc/designer-manual.html user documentation].


;Step 0:
Call QtCreator
<syntaxhighlight lang="bash">
qtcreator
</syntaxhighlight>
Then select New File or Project -> Qt C++ Project -> Qt Gui Application -> name = helloworld -> Next -> Next -> Finish


;Step 1:
Select Edit -> Forms -> mainwindow.ui. Add the widgets you want by drag-and-drop:


[[File:Designer-step1.png|200px]]


;Step 2:
Select the mainwindow. This is the one un-intuitive step. To lay out the objects in the mainwindow, you do not select the objects in the mainwindow, but the mainwindow itself.


[[File:Designer-step2.png|200px]]


;Step 3:
Select Form -> Lay Out in a <u>G</u>rid


[[File:Designer-step3.png|200px]]


;Result:
You get a decent look, and if you resize the window, the widgets resize as well.


[[File:Designer-result.png|200px]]

=== Using KDE libraries === 


To use KDE classes like KMessageBox, you need to tell QtCreator to use the KDE libraries when building. Go to your home directory, change into ''yourproject'' and modify ''yourproject.pro''. Add the line
<syntaxhighlight lang="make">
LIBS += -lkdeui
</syntaxhighlight>
Then you can start using KDE classes in your code.

=== Adding a toolbar === 


To add a toolbar, right-click on the UI and choose "Add Toolbar". Then you can set icons and text in your mainwindow's constructor with code like this:
<syntaxhighlight lang="cpp-qt">
ui->toolBar->addAction(QIcon("/usr/share/icons/oxygen/22x22/apps/ktip.png"),"hello world");
</syntaxhighlight>
[[Development/Tutorials/Using_Qt_Designer|More Info...]]

== Load an existing project == 


This describes how to use QtCreator to integrate existing KDE 4 applications. It has been tested with QtCreator 1.2.80 and SUSE Linux 11.1 but should work same or similar with every combination. As an example KDE application we use [http://userbase.kde.org/ktimetracker ktimetracker] from the kdepim module, other applications should work likewise.


You can either work with code on your disk or have QtCreator do the repository checkout.

=== use code from your disk === 


* import the CMakeLists.txt file (File -> Open -> kdepim/CMakeLists.txt)
* as build directory choose kdepim
* you will automatically come to a screen where you can run CMake
* continue with the step "Run cmake"

=== have QtCreator do the git checkout === 


* choose File -> New File or Project -> Project from Version Control -> Git Repository Clone.
* enter a Git URL like git@git.kde.org:/kdepim
* accept kdepim as checkout directory
* type finish, see how the checkout starts
* you will automatically come to a screen where you can run CMake
* continue with the step "Run cmake"

=== have QtCreator do the subversion checkout === 


* choose File -> New File or Project -> Version Control -> Subversion Checkout.
* enter a Subversion URL like svn://anonsvn.kde.org/home/kde/trunk/KDE/kdepim
* enter a checkout directory, i.e. the local directory where the code will be checked-out to
* type finish, see how the checkout starts
* you will automatically come to a screen where you can run CMake
* continue with the step "Run cmake"

=== Run cmake === 


* enter arguments for CMake like
<syntaxhighlight lang="bash">
/root/kdepim -DCMAKE_INSTALL_PREFIX=/usr/local -DLIB_SUFFIX=64 -DCMAKE_BUILD_TYPE=debugfull
</syntaxhighlight>
<tt>DLIB_SUFFIX=64</tt> means that you want to install your libraries into directories named <tt>lib64</tt>, not <tt>lib</tt>. ''/root/kdepim'' is where your source code is.
* click "Run cmake"
* note: a .cbp file is created containing many information about the build
* click "Finish"

=== Build it === 


* configure QtCreator to build only ktimetracker:
Projects -> Active run configuration=ktimetracker -> build settings -> build steps -> make -> show details -> activate ktimetracker.
* configure QtCreator to use 8 logical processors:
Projects -> Active run configuration=ktimetracker -> build settings -> build steps -> make -> show details -> addtional Arguments = -j8
* choose Build -> Build All

== See also == 


* [[Development/Tutorials/Using Qt Designer]]
* [[Getting_Started/Using_an_IDE_with_KDE4#QtCreator]]
</translate>
[[Category:KDE4]]

Development/Tutorials/Using Qt Creator

2013-01-27T08:36:36Z

Tstaerk: subversion -> git

<languages />
<translate>

__TOC__


QtCreator is an IDE from Nokia for Qt. It contains QtDesigner for UI design. This article describes:
* why to use Qt Creator
* how to create a new application
* how to load an existing application

== Why use Qt Creator == 


{|align="right"
|[[image:Snapshot-qtcreator.png|right|thumb|200px|KDE4's ktimetracker loaded as QtCreator project]]
|}
To create your C++ applications you can use any text editor. But life will be much easier if you gain QtCreator's features. That means
* you can get your source code saved, built and run with one click
* you get code-completion
* you can find all places in your source code where you call a function (e.g. "where do I call refresh()")
* you can go back to a more recent cursor position with your editor, even if this is in another file
* you can checkout and commit to Subversion or Git repositories without leaving your workflow

== Creating a new program == 


Here is a short example of how you can create a "hello world" application. For more information read the [http://qt.nokia.com/doc/designer-manual.html user documentation].


;Step 0:
Call QtCreator
<syntaxhighlight lang="bash">
qtcreator
</syntaxhighlight>
Then select New File or Project -> Qt C++ Project -> Qt Gui Application -> name = helloworld -> Next -> Next -> Finish


;Step 1:
Select Edit -> Forms -> mainwindow.ui. Add the widgets you want by drag-and-drop:


[[File:Designer-step1.png|200px]]


;Step 2:
Select the mainwindow. This is the one un-intuitive step. To lay out the objects in the mainwindow, you do not select the objects in the mainwindow, but the mainwindow itself.


[[File:Designer-step2.png|200px]]


;Step 3:
Select Form -> Lay Out in a <u>G</u>rid


[[File:Designer-step3.png|200px]]


;Result:
You get a decent look, and if you resize the window, the widgets resize as well.


[[File:Designer-result.png|200px]]

=== Using KDE libraries === 


To use KDE classes like KMessageBox, you need to tell QtCreator to use the KDE libraries when building. Go to your home directory, change into ''yourproject'' and modify ''yourproject.pro''. Add the line
<syntaxhighlight lang="make">
LIBS += -lkdeui
</syntaxhighlight>
Then you can start using KDE classes in your code.

=== Adding a toolbar === 


To add a toolbar, right-click on the UI and choose "Add Toolbar". Then you can set icons and text in your mainwindow's constructor with code like this:
<syntaxhighlight lang="cpp-qt">
ui->toolBar->addAction(QIcon("/usr/share/icons/oxygen/22x22/apps/ktip.png"),"hello world");
</syntaxhighlight>
[[Development/Tutorials/Using_Qt_Designer|More Info...]]

== Load an existing project == 


This describes how to use QtCreator to integrate existing KDE 4 applications. It has been tested with QtCreator 1.2.80 and SUSE Linux 11.1 but should work same or similar with every combination. As an example KDE application we use [http://userbase.kde.org/ktimetracker ktimetracker] from the kdepim module, other applications should work likewise.


You can either work with code on your disk or have QtCreator do the repository checkout.

=== use code from your disk === 


* import the CMakeLists.txt file (File -> Open -> kdepim/CMakeLists.txt)
* as build directory choose kdepim
* you will automatically come to a screen where you can run CMake
* continue with the step "Run cmake"

=== have QtCreator do the subversion checkout === 


* choose File -> New File or Project -> Version Control -> Subversion Checkout.
* enter a Subversion URL like svn://anonsvn.kde.org/home/kde/trunk/KDE/kdepim
* enter a checkout directory, i.e. the local directory where the code will be checked-out to
* type finish, see how the checkout starts
* you will automatically come to a screen where you can run CMake
* continue with the step "Run cmake"

=== have QtCreator do the git checkout === 


* choose File -> New File or Project -> Project from Version Control -> Git Repository Clone.
* enter a Git URL like git@git.kde.org:/kdepim
* accept kdepim as checkout directory
* type finish, see how the checkout starts
* you will automatically come to a screen where you can run CMake
* continue with the step "Run cmake"

=== Run cmake === 


* enter arguments for CMake like
<syntaxhighlight lang="bash">
/root/kdepim -DCMAKE_INSTALL_PREFIX=/usr/local -DLIB_SUFFIX=64 -DCMAKE_BUILD_TYPE=debugfull
</syntaxhighlight>
<tt>DLIB_SUFFIX=64</tt> means that you want to install your libraries into directories named <tt>lib64</tt>, not <tt>lib</tt>. ''/root/kdepim'' is where your source code is.
* click "Run cmake"
* note: a .cbp file is created containing many information about the build
* click "Finish"

=== Build it === 


* configure QtCreator to build only ktimetracker:
Projects -> Active run configuration=ktimetracker -> build settings -> build steps -> make -> show details -> activate ktimetracker.
* configure QtCreator to use 8 logical processors:
Projects -> Active run configuration=ktimetracker -> build settings -> build steps -> make -> show details -> addtional Arguments = -j8
* choose Build -> Build All

== See also == 


* [[Development/Tutorials/Using Qt Designer]]
* [[Getting_Started/Using_an_IDE_with_KDE4#QtCreator]]
</translate>
[[Category:KDE4]]

Getting Started/Build/KDE4/on virtual machines

2013-01-27T08:34:53Z

Tstaerk: qtcreatOr

{{Infobox tutorial|time=3 hours|type=HowTo|distribution=SUSE Linux 12.2|happyreaders=2|unhappyreaders=0}}

This describes how to use a virtual machine for building the latest KDE from sources.

= Virtual Machine Setup =
Create a virtual machine, e.g. using [http://www.linuxintro.org/wiki/VirtualbOx VirtualBox]. Regarding harddisk: KDE 4 fits into 10 GB, however [[User:Tstaerk|I]] recommend 40GB, one partition. Regarding RAM: You will need at least 1GB ram for the virtual machine, of course more is better.

;You will need to set your SUSE CD as your virtual machine's cdrom.

== setup for SSH ==
To be able to log in to your VM using ssh, stop and disable the firewall:
rcSuSEfirewall2 stop
chkconfig SuSEfirewall2_setup off
chkconfig SuSEfirewall2_init off
/etc/init.d/sshd start
chkconfig sshd on
Inside the VM, install some needed packages:
yast -i libqt4-devel pcre-devel libxslt-devel libxml2-devel docbook-xsl-stylesheets git cyrus-sasl-devel libiodbc-devel \
libdbusmenu-qt-devel giflib-devel strigi-devel libQtWebKit-devel libqimageblitz-devel libical-devel libgpgme-devel \
boost-devel libqjson-devel libredland-devel xcb-util-image-devel

;Now it is time to do a snapshot or clone from your VM.
You will be able to return to this machine state whenever you want.

== a few more steps ==
[http://www.linuxintro.org/wiki/open_a_console Open a console] as root
su -

== on an x64 distribution ==
If and only if you have a /lib64 path, you are on an x64 distribution.
Make sure you have the needed environment variables and alias set by having a file /root/.bashrc.
cd
cat >.bashrc<<EOF
export KDEDIR=/usr/local
alias cmakekde="cmake . -DCMAKE_INSTALL_PREFIX=\$KDEDIR -DLIB_SUFFIX=64 -D[[Development/CMake/Addons_for_KDE#Buildtypes|CMAKE_BUILD_TYPE]]=debugfull && make -j8 && make install"
alias cmakekdelibs="cmake ../kdelibs -DCMAKE_INSTALL_PREFIX=\$KDEDIR -DLIB_SUFFIX=64 -DCMAKE_BUILD_TYPE=debugfull && make -j8 && make install"
alias makeqt="./configure -dbus -openssl -plugin-sql-mysql -libdir /usr/lib64 -prefix /usr && make -j8 && make install"
export QTDIR=/usr
EOF
cat >.gitconfig<<EOF
[url "git://anongit.kde.org/"]
insteadOf = kde:
[url "ssh://git@git.kde.org/"]
pushInsteadOf = kde:
EOF
Now activate this file
. /root/.bashrc

== on another distribution (incl 32bit)==
Make sure you have the needed environment variables and alias set by having a file /root/.bashrc.
cd
cat >.bashrc<<EOF
export KDEDIR=/usr/local
alias cmakekde="cmake . -DCMAKE_INSTALL_PREFIX=\$KDEDIR -DCMAKE_BUILD_TYPE=debugfull && make -j8 && make install"
alias cmakekdelibs="cmake ../kdelibs -DCMAKE_INSTALL_PREFIX=\$KDEDIR -DCMAKE_BUILD_TYPE=debugfull && make -j8 && make install"
alias makeqt="./configure -dbus -openssl -plugin-sql-mysql -prefix /usr && make -j8 && make install"
export QTDIR=/usr
EOF
cat >.gitconfig<<EOF
[url "git://anongit.kde.org/"]
insteadOf = kde:
[url "ssh://git@git.kde.org/"]
pushInsteadOf = kde:
EOF
Now activate this file
. /root/.bashrc

= Aquire and Build KDE as root =
If something fails you may need to make clean and rm CMakeCache.

== cmake ==
Install the latest version of cmake:
cd
wget http://www.cmake.org/files/v2.8/cmake-2.8.10.2.tar.gz
tar xvzf cmake-2.8.10.2.tar.gz
cd cmake-2.8.10.2
./configure && make -j4 && make install

== automoc ==
automoc is needed for akonadi.
cd
git clone kde:automoc
cd automoc
cmakekde

== libattica ==
cd
git clone kde:attica
cd attica
cmakekde

== shared desktop ontologies ==
shared desktop ontologies is needed by kdepimlibs in order to build Nepomuk (which is a part of kdelibs)
cd
wget http://downloads.sourceforge.net/project/oscaf/shared-desktop-ontologies/0.10.0/shared-desktop-ontologies-0.10.0.tar.bz2
tar xvjf shared-desktop-ontologies-0.10.0.tar.bz2
cd shared-desktop-ontologies-0.10.0/
cmake . && make && make install

== soprano ==
cd
git clone kde:soprano
cd soprano
cmakekde

== phonon ==
Phonon is needed for kdebase-runtime
cd
git clone kde:phonon
cd phonon
cmakekde

== akonadi ==
Akonadi keeps personal information management data in a mysql database. It is needed for KDEPIMLIBS.
cd
git clone kde:akonadi
cd akonadi
cmakekde

== kdelibs ==
KDELIBS requires an out-of-source build, that is why it is more complicated to build:
cd
git clone kde:kdelibs
mkdir kdelibs-build
cd kdelibs-build
cmakekdelibs
Verify it has been correctly installed - the following must be possible:
kde4-config --prefix
/usr/local

== nepomuk-core ==
cd
git clone kde:nepomuk-core
cd nepomuk-core
cmakekde

== kdepimlibs ==
kdepimlibs is needed for kde-runtime.
cd
git clone kde:kdepimlibs
cd kdepimlibs
cmakekde

== kactivities ==
kactivities is needed for kde-workspace.
cd
git clone kde:kactivities
cd kactivities
cmakekde

== kdebase ==
cd
git clone kde:kde-baseapps
git clone kde:konsole
git clone kde:kde-workspace
git clone kde:kde-runtime
cd kde-baseapps
cmakekde
cd
cd konsole
cmakekde
cd
cd kde-workspace
cmakekde
cd
cd kde-runtime
cmakekde

= Next step =
Now you can start developing. Best, install QtCreator:
yast -i qt-creator
And learn how to create a new KDE project or import an existing one by reading [[qtcreator]].

Getting Started/Build/KDE4/on virtual machines

2013-01-27T08:14:46Z

Tstaerk: xcb-util-image-devel is needed for kde-workspace

Getting Started/Build/KDE4/on virtual machines

2013-01-26T22:06:16Z

Tstaerk: /* Aquire and Build KDE as root */

{{Infobox tutorial|time=3 hours|type=HowTo|distribution=SUSE Linux 12.2|happyreaders=2|unhappyreaders=0}}

This describes how to use a virtual machine for building the latest KDE from sources.

= Virtual Machine Setup =
Create a virtual machine, e.g. using [http://www.linuxintro.org/wiki/VirtualbOx VirtualBox]. Regarding harddisk: KDE 4 fits into 10 GB, however [[User:Tstaerk|I]] recommend 40GB, one partition. Regarding RAM: You will need at least 1GB ram for the virtual machine, of course more is better.

;You will need to set your SUSE CD as your virtual machine's cdrom.

== setup for SSH ==
To be able to log in to your VM using ssh, stop and disable the firewall:
rcSuSEfirewall2 stop
chkconfig SuSEfirewall2_setup off
chkconfig SuSEfirewall2_init off
/etc/init.d/sshd start
chkconfig sshd on
Inside the VM, install some needed packages:
yast -i libqt4-devel pcre-devel libxslt-devel libxml2-devel docbook-xsl-stylesheets git cyrus-sasl-devel libiodbc-devel \
libdbusmenu-qt-devel giflib-devel strigi-devel libQtWebKit-devel libqimageblitz-devel libical-devel libgpgme-devel \
boost-devel libqjson-devel libredland-devel

;Now it is time to do a snapshot or clone from your VM.
You will be able to return to this machine state whenever you want.

== a few more steps ==
[http://www.linuxintro.org/wiki/open_a_console Open a console] as root
su -

== on an x64 distribution ==
If and only if you have a /lib64 path, you are on an x64 distribution.
Make sure you have the needed environment variables and alias set by having a file /root/.bashrc.
cd
cat >.bashrc<<EOF
export KDEDIR=/usr/local
alias cmakekde="cmake . -DCMAKE_INSTALL_PREFIX=\$KDEDIR -DLIB_SUFFIX=64 -D[[Development/CMake/Addons_for_KDE#Buildtypes|CMAKE_BUILD_TYPE]]=debugfull && make -j8 && make install"
alias cmakekdelibs="cmake ../kdelibs -DCMAKE_INSTALL_PREFIX=\$KDEDIR -DLIB_SUFFIX=64 -DCMAKE_BUILD_TYPE=debugfull && make -j8 && make install"
alias makeqt="./configure -dbus -openssl -plugin-sql-mysql -libdir /usr/lib64 -prefix /usr && make -j8 && make install"
export QTDIR=/usr
EOF
cat >.gitconfig<<EOF
[url "git://anongit.kde.org/"]
insteadOf = kde:
[url "ssh://git@git.kde.org/"]
pushInsteadOf = kde:
EOF
Now activate this file
. /root/.bashrc

== on another distribution (incl 32bit)==
Make sure you have the needed environment variables and alias set by having a file /root/.bashrc.
cd
cat >.bashrc<<EOF
export KDEDIR=/usr/local
alias cmakekde="cmake . -DCMAKE_INSTALL_PREFIX=\$KDEDIR -DCMAKE_BUILD_TYPE=debugfull && make -j8 && make install"
alias cmakekdelibs="cmake ../kdelibs -DCMAKE_INSTALL_PREFIX=\$KDEDIR -DCMAKE_BUILD_TYPE=debugfull && make -j8 && make install"
alias makeqt="./configure -dbus -openssl -plugin-sql-mysql -prefix /usr && make -j8 && make install"
export QTDIR=/usr
EOF
cat >.gitconfig<<EOF
[url "git://anongit.kde.org/"]
insteadOf = kde:
[url "ssh://git@git.kde.org/"]
pushInsteadOf = kde:
EOF
Now activate this file
. /root/.bashrc

= Aquire and Build KDE as root =
If something fails you may need to make clean and rm CMakeCache.

== cmake ==
Install the latest version of cmake:
cd
wget http://www.cmake.org/files/v2.8/cmake-2.8.10.2.tar.gz
tar xvzf cmake-2.8.10.2.tar.gz
cd cmake-2.8.10.2
./configure && make -j4 && make install

== automoc ==
automoc is needed for akonadi.
cd
git clone kde:automoc
cd automoc
cmakekde

== libattica ==
cd
git clone kde:attica
cd attica
cmakekde

== shared desktop ontologies ==
shared desktop ontologies is needed by kdepimlibs in order to build Nepomuk (which is a part of kdelibs)
cd
wget http://downloads.sourceforge.net/project/oscaf/shared-desktop-ontologies/0.10.0/shared-desktop-ontologies-0.10.0.tar.bz2
tar xvjf shared-desktop-ontologies-0.10.0.tar.bz2
cd shared-desktop-ontologies-0.10.0/
cmake . && make && make install

== soprano ==
cd
git clone kde:soprano
cd soprano
cmakekde

== phonon ==
Phonon is needed for kdebase-runtime
cd
git clone kde:phonon
cd phonon
cmakekde

== akonadi ==
Akonadi keeps personal information management data in a mysql database. It is needed for KDEPIMLIBS.
cd
git clone kde:akonadi
cd akonadi
cmakekde

== kdelibs ==
KDELIBS requires an out-of-source build, that is why it is more complicated to build:
cd
git clone kde:kdelibs
mkdir kdelibs-build
cd kdelibs-build
cmakekdelibs
Verify it has been correctly installed - the following must be possible:
kde4-config --prefix
/usr/local

== nepomuk-core ==
cd
git clone kde:nepomuk-core
cd nepomuk-core
cmakekde

== kdepimlibs ==
kdepimlibs is needed for kde-runtime.
cd
git clone kde:kdepimlibs
cd kdepimlibs
cmakekde

== kactivities ==
kactivities is needed for kde-workspace.
cd
git clone kde:kactivities
cd kactivities
cmakekde

== kdebase ==
cd
git clone kde:kde-baseapps
git clone kde:konsole
git clone kde:kde-workspace
git clone kde:kde-runtime
cd kde-baseapps
cmakekde
cd
cd konsole
cmakekde
cd
cd kde-workspace
cmakekde
cd
cd kde-runtime
cmakekde

Getting Started/Build/KDE4/on virtual machines

2013-01-26T21:32:05Z

Tstaerk: /* setup for SSH */

{{Infobox tutorial|time=3 hours|type=HowTo|distribution=SUSE Linux 12.2|happyreaders=2|unhappyreaders=0}}

This describes how to use a virtual machine for building the latest KDE from sources.

= Virtual Machine Setup =
Create a virtual machine, e.g. using [http://www.linuxintro.org/wiki/VirtualbOx VirtualBox]. Regarding harddisk: KDE 4 fits into 10 GB, however [[User:Tstaerk|I]] recommend 40GB, one partition. Regarding RAM: You will need at least 1GB ram for the virtual machine, of course more is better.

;You will need to set your SUSE CD as your virtual machine's cdrom.

== setup for SSH ==
To be able to log in to your VM using ssh, stop and disable the firewall:
rcSuSEfirewall2 stop
chkconfig SuSEfirewall2_setup off
chkconfig SuSEfirewall2_init off
/etc/init.d/sshd start
chkconfig sshd on
Inside the VM, install some needed packages:
yast -i libqt4-devel pcre-devel libxslt-devel libxml2-devel docbook-xsl-stylesheets git cyrus-sasl-devel libiodbc-devel \
libdbusmenu-qt-devel giflib-devel strigi-devel libQtWebKit-devel libqimageblitz-devel libical-devel libgpgme-devel \
boost-devel libqjson-devel libredland-devel

;Now it is time to do a snapshot or clone from your VM.
You will be able to return to this machine state whenever you want.

== a few more steps ==
[http://www.linuxintro.org/wiki/open_a_console Open a console] as root
su -

== on an x64 distribution ==
If and only if you have a /lib64 path, you are on an x64 distribution.
Make sure you have the needed environment variables and alias set by having a file /root/.bashrc.
cd
cat >.bashrc<<EOF
export KDEDIR=/usr/local
alias cmakekde="cmake . -DCMAKE_INSTALL_PREFIX=\$KDEDIR -DLIB_SUFFIX=64 -D[[Development/CMake/Addons_for_KDE#Buildtypes|CMAKE_BUILD_TYPE]]=debugfull && make -j8 && make install"
alias cmakekdelibs="cmake ../kdelibs -DCMAKE_INSTALL_PREFIX=\$KDEDIR -DLIB_SUFFIX=64 -DCMAKE_BUILD_TYPE=debugfull && make -j8 && make install"
alias makeqt="./configure -dbus -openssl -plugin-sql-mysql -libdir /usr/lib64 -prefix /usr && make -j8 && make install"
export QTDIR=/usr
EOF
cat >.gitconfig<<EOF
[url "git://anongit.kde.org/"]
insteadOf = kde:
[url "ssh://git@git.kde.org/"]
pushInsteadOf = kde:
EOF
Now activate this file
. /root/.bashrc

== on another distribution (incl 32bit)==
Make sure you have the needed environment variables and alias set by having a file /root/.bashrc.
cd
cat >.bashrc<<EOF
export KDEDIR=/usr/local
alias cmakekde="cmake . -DCMAKE_INSTALL_PREFIX=\$KDEDIR -DCMAKE_BUILD_TYPE=debugfull && make -j8 && make install"
alias cmakekdelibs="cmake ../kdelibs -DCMAKE_INSTALL_PREFIX=\$KDEDIR -DCMAKE_BUILD_TYPE=debugfull && make -j8 && make install"
alias makeqt="./configure -dbus -openssl -plugin-sql-mysql -prefix /usr && make -j8 && make install"
export QTDIR=/usr
EOF
cat >.gitconfig<<EOF
[url "git://anongit.kde.org/"]
insteadOf = kde:
[url "ssh://git@git.kde.org/"]
pushInsteadOf = kde:
EOF
Now activate this file
. /root/.bashrc

= Aquire and Build KDE as root =
If something fails you may need to make clean.

== cmake ==
Install the latest version of cmake:
cd
wget http://www.cmake.org/files/v2.8/cmake-2.8.10.2.tar.gz
tar xvzf cmake-2.8.10.2.tar.gz
cd cmake-2.8.10.2
./configure && make -j4 && make install

== automoc ==
automoc is needed for akonadi.
cd
git clone kde:automoc
cd automoc
cmakekde

== akonadi ==
Akonadi keeps personal information management data in a mysql database. It is needed for KDEPIMLIBS.
cd
git clone kde:akonadi
cd akonadi
cmakekde

== libattica ==
cd
git clone kde:attica
cd attica
cmakekde

== shared desktop ontologies ==
shared desktop ontologies is needed by kdepimlibs in order to build Nepomuk (which is a part of kdelibs)
cd
wget http://downloads.sourceforge.net/project/oscaf/shared-desktop-ontologies/0.10.0/shared-desktop-ontologies-0.10.0.tar.bz2
tar xvjf shared-desktop-ontologies-0.10.0.tar.bz2
cd shared-desktop-ontologies-0.10.0/
cmake . && make && make install

== soprano ==
cd
git clone kde:soprano
cd soprano
cmakekde

== phonon ==
Phonon is needed for kdebase-runtime
cd
git clone kde:phonon
cd phonon
cmakekde

== kdelibs ==
KDELIBS requires an out-of-source build, that is why it is more complicated to build:
cd
git clone kde:kdelibs
mkdir kdelibs-build
cd kdelibs-build
cmakekdelibs
Verify it has been correctly installed - the following must be possible:
kde4-config --prefix
/usr/local

== nepomuk-core ==
cd
git clone kde:nepomuk-core
cd nepomuk-core
cmakekde

== kdepimlibs ==
kdepimlibs is needed for kde-runtime.
cd
git clone kde:kdepimlibs
cd kdepimlibs
cmakekde

== kactivities ==
kactivities is needed for kde-workspace.
cd
git clone kde:kactivities
cd kactivities
cmakekde

== kdebase ==
cd
git clone kde:kde-baseapps
git clone kde:konsole
git clone kde:kde-workspace
git clone kde:kde-runtime
cd kde-baseapps
cmakekde
cd
cd konsole
cmakekde
cd
cd kde-workspace
cmakekde
cd
cd kde-runtime
cmakekde

Getting Started/Build/KDE4/on virtual machines

2013-01-26T19:38:09Z

Tstaerk: /* setup for SSH */

{{Infobox tutorial|time=3 hours|type=HowTo|distribution=SUSE Linux 12.2|happyreaders=2|unhappyreaders=0}}

This describes how to use a virtual machine for building the latest KDE from sources.

= Virtual Machine Setup =
Create a virtual machine, e.g. using [http://www.linuxintro.org/wiki/VirtualbOx VirtualBox]. Regarding harddisk: KDE 4 fits into 10 GB, however [[User:Tstaerk|I]] recommend 40GB, one partition. Regarding RAM: You will need at least 1GB ram for the virtual machine, of course more is better.

;You will need to set your SUSE CD as your virtual machine's cdrom.

== setup for SSH ==
To be able to log in to your VM using ssh, stop and disable the firewall:
rcSuSEfirewall2 stop
chkconfig SuSEfirewall2_setup off
chkconfig SuSEfirewall2_init off
/etc/init.d/sshd start
chkconfig sshd on
Inside the VM, install some needed packages:
yast -i libqt4-devel pcre-devel libxslt-devel libxml2-devel docbook-xsl-stylesheets git cyrus-sasl-devel libiodbc-devel \
libdbusmenu-qt-devel giflib-devel strigi-devel libQtWebKit-devel libqimageblitz-devel libical-devel libgpgme-devel \
boost-devel libqjson-devel

;Now it is time to do a snapshot or clone from your VM.
You will be able to return to this machine state whenever you want.

== a few more steps ==
[http://www.linuxintro.org/wiki/open_a_console Open a console] as root
su -

== on an x64 distribution ==
If and only if you have a /lib64 path, you are on an x64 distribution.
Make sure you have the needed environment variables and alias set by having a file /root/.bashrc.
cd
cat >.bashrc<<EOF
export KDEDIR=/usr/local
alias cmakekde="cmake . -DCMAKE_INSTALL_PREFIX=\$KDEDIR -DLIB_SUFFIX=64 -D[[Development/CMake/Addons_for_KDE#Buildtypes|CMAKE_BUILD_TYPE]]=debugfull && make -j8 && make install"
alias cmakekdelibs="cmake ../kdelibs -DCMAKE_INSTALL_PREFIX=\$KDEDIR -DLIB_SUFFIX=64 -DCMAKE_BUILD_TYPE=debugfull && make -j8 && make install"
alias makeqt="./configure -dbus -openssl -plugin-sql-mysql -libdir /usr/lib64 -prefix /usr && make -j8 && make install"
export QTDIR=/usr
EOF
cat >.gitconfig<<EOF
[url "git://anongit.kde.org/"]
insteadOf = kde:
[url "ssh://git@git.kde.org/"]
pushInsteadOf = kde:
EOF
Now activate this file
. /root/.bashrc

== on another distribution (incl 32bit)==
Make sure you have the needed environment variables and alias set by having a file /root/.bashrc.
cd
cat >.bashrc<<EOF
export KDEDIR=/usr/local
alias cmakekde="cmake . -DCMAKE_INSTALL_PREFIX=\$KDEDIR -DCMAKE_BUILD_TYPE=debugfull && make -j8 && make install"
alias cmakekdelibs="cmake ../kdelibs -DCMAKE_INSTALL_PREFIX=\$KDEDIR -DCMAKE_BUILD_TYPE=debugfull && make -j8 && make install"
alias makeqt="./configure -dbus -openssl -plugin-sql-mysql -prefix /usr && make -j8 && make install"
export QTDIR=/usr
EOF
cat >.gitconfig<<EOF
[url "git://anongit.kde.org/"]
insteadOf = kde:
[url "ssh://git@git.kde.org/"]
pushInsteadOf = kde:
EOF
Now activate this file
. /root/.bashrc

= Aquire and Build KDE as root =
If something fails you may need to make clean.

== cmake ==
Install the latest version of cmake:
cd
wget http://www.cmake.org/files/v2.8/cmake-2.8.10.2.tar.gz
tar xvzf cmake-2.8.10.2.tar.gz
cd cmake-2.8.10.2
./configure && make -j4 && make install

== automoc ==
automoc is needed for akonadi.
cd
git clone kde:automoc
cd automoc
cmakekde

== akonadi ==
Akonadi keeps personal information management data in a mysql database. It is needed for KDEPIMLIBS.
cd
git clone kde:akonadi
cd akonadi
cmakekde

== libattica ==
cd
git clone kde:attica
cd attica
cmakekde

== shared desktop ontologies ==
shared desktop ontologies is needed by kdepimlibs in order to build Nepomuk (which is a part of kdelibs)
cd
wget http://downloads.sourceforge.net/project/oscaf/shared-desktop-ontologies/0.10.0/shared-desktop-ontologies-0.10.0.tar.bz2
tar xvjf shared-desktop-ontologies-0.10.0.tar.bz2
cd shared-desktop-ontologies-0.10.0/
cmake . && make && make install

== soprano ==
cd
git clone kde:soprano
cd soprano
cmakekde

== phonon ==
Phonon is needed for kdebase-runtime
cd
git clone kde:phonon
cd phonon
cmakekde

== kdelibs ==
KDELIBS requires an out-of-source build, that is why it is more complicated to build:
cd
git clone kde:kdelibs
mkdir kdelibs-build
cd kdelibs-build
cmakekdelibs
Verify it has been correctly installed - the following must be possible:
kde4-config --prefix
/usr/local

== nepomuk-core ==
cd
git clone kde:nepomuk-core
cd nepomuk-core
cmakekde

== kdepimlibs ==
kdepimlibs is needed for kde-runtime.
cd
git clone kde:kdepimlibs
cd kdepimlibs
cmakekde

== kactivities ==
kactivities is needed for kde-workspace.
cd
git clone kde:kactivities
cd kactivities
cmakekde

== kdebase ==
cd
git clone kde:kde-baseapps
git clone kde:konsole
git clone kde:kde-workspace
git clone kde:kde-runtime
cd kde-baseapps
cmakekde
cd
cd konsole
cmakekde
cd
cd kde-workspace
cmakekde
cd
cd kde-runtime
cmakekde

Getting Started/Build

2013-01-26T19:21:26Z

Tstaerk: working example does not work

{{warning|These pages are currently being completely re-written to reflect the new KDE infrastructure and may not be in a consistent state. Information and commands on some page may no longer be valid and should be used with care.}}

== Introduction ==

This page provides an overview of the KDE build process. Once you complete the steps described here you will have a complete KDE development system customized to your needs.

== Build Steps ==

This section will briefly explain the concepts and steps involved in building software so you are not being asked to blindly follow some recipes you do not understand.

It is assumed you are at least familiar with the basics of using the command line.

Once you have read the summary you can see a [[Getting_Started/Build/KDE4/on_virtual_machines|working example on a virtual machine here]].

=== Source ===

The ''Source'' step is obtaining a local copy of the source code that you want to build. For a detailed explanation of where to obtain the source code and how KDE stores and organizes our source code please read the [[Getting_Started/Sources|KDE Sources section]].

The two main options here are to either download a snapshot tarball of the code, or to directly access the source code repository. For developing on the unstable branch of the KDE SC it is recommended you directly access the required repositories.

=== Configure ===

The ''Configure'' step is setting up how the source code is to be built and installed.

=== Build ===

The ''Build'' step is compiling the source code and linking it to other libraries to create the new executables and libraries.

=== Install ===

The ''Install'' step is copy the new executables and libraries somewhere that they can be found and run from.

=== Update ===

The ''Update'' step is updating an existing build to use the latest version of the source code and then re-building and re-installing it.

== Scripted Builds ==

The easiest way to build the KDE SC from scratch is to use one of the build scripts that are available. This approach is highly recommended for those new to building KDE SC as it takes care of the Source, Configure, Build, Install and Update steps for you. The builds remain compatible with the manual methods of building KDE SC so you can change later if you want.

Even KDE Core Developers use build scripts like these as opposed to doing everything manually, as there's just no point otherwise.

If you run into any issues, be sure to ask either on the kde-devel mailing list, or the #kde-devel IRC channel (which many developers reside in and are willing to ask any questions or address any problems encountered).

=== kdesrc-build ===
[[/kdesrc-build|kdesrc-build]] (formerly kdesvn-build) is a tool to allow users and developers to easily download and build the latest versions of the KDE Software Compilation (KDE SC) from the KDE source code repositories.

=== build-tool ===
The [http://michael-jansen.biz/build-tool build-tool] is a ruby program script which is meant not for just building KDE, but also can easily be expanded to compile any other applications. It also has some neat features like progress bars and eta for compile time. It can also automatically generate a ~/.xsessionrc which can be used by KDM when you select to boot into a "Custom" session type. That will enable you to easily get into a KDE session which was built from source, without even having to modify any of your scripts like ~/.bashrc, ~/.zshrc, etc.

Install rubygems through your package manager. Run <tt>sudo gem install build-tool</tt>. Now that build-tool is installed, we need to install the KDE recipes to have it build KDE from source. Run <tt>build-tool recipe add git://gitorious.org/build-tool/kde-trunk-recipe.git kde</tt> to add the KDE recipe to the program. Then <tt>build-tool recipes install kde</tt>. From there, you can run <tt>kde-build help</tt> to see the commands available for the KDE recipe, as well as compile and update the git repositories.

For more detailed information, visit: http://michael-jansen.biz/build-tool

== Platform Specific Information ==

The build process described in these pages is kept as simple and generic as possible, but it is generally assumed you are building KDE4 on Linux. Extra information about building KDE Software on specific distributions or platforms, or under certain conditions can be found at the following links:

* [[/Distributions|Linux, BSD and other *nix based distributions]]
* [[/Windows|Microsoft Windows]]
* [[/Mac_OS_X|Apple Mac OS X]]
* [[/KDE4/on_virtual_machines|On a Virtual Machine]].
* [[/Historic|Building historic versions of KDE Software (KDE3 and KDE2)]]

== Stable versus Unstable ==

A stable build is a released and supported version of KDE Software, such as KDE SC 4.6. This software is guaranteed to remain unchanged other than bug-fixes. You will want a Stable build if you want to use the KDE Software for normal use or to develop bug fixes.

An unstable build is the latest development version of KDE Software and is not guaranteed to build or run properly at any given time. You will want an Unstable build if you want to develop new features for KDE Software.

In Git, the Unstable branch is called Master while in Subversion it is called Trunk.

== Build and Install ==

You need to complete each of the following steps to build and/or install a working KDE development system. Manually building KDE Software requires that you first set up the build environment and install the required development tools and libraries.

* Choose the appropriate [[/Methods|Build Method]] for your requirements
* Set up your [[/Environment|Build Environment]]
* Choose the appropriate [[/Recipes|Build Recipes]] for your requirements and environment
* Install the [[/Requirements|Build Requirements]]
* Install or build [[/Qt|Qt]]
* Install or build [[/KDE_Support|KDE Support]]
* Install or build [[/KDE_Development_Platform|KDE Development Platform]]
* Install or build [[/KDE_Workspace|KDE Workspace]]
* [[/KDE_Applications|Build KDE Applications]]

== Troubleshooting The Build ==

Compile and Linking errors are frequent sources of discouragement. Make careful note of the first occurrence of an error in your build process. It could be as simple as a bad environment variable, an unexpected version of a library or missing prerequisite. Please read the instructions carefully.

Please review your logs and do searches for fixes. If you cannot find a solution, try the [[/Troubleshooting|Troubleshooting]] page. If you still cannot resolve the problem then please [[Development/Getting_Help|ask for help]] on IRC or a Mailing List.

== Starting KDE ==

Having built and installed KDE, you will probably want to start it. Launching a full session requires some preparations, depending on whether you want to run the self-compiled KDE within another desktop environment or as a full-blow session:

* [[Getting_Started/Run/Nested_Session|How to Run a nested session of KDE]]
* [[Getting_Started/Run/Full_Session|How to Run a full session of KDE]]

[[Category:Build KDE]]

Getting Started/Build/KDE4/on virtual machines

2013-01-26T19:13:49Z

Tstaerk: you will need libiodbc-devel for sesame which you need for soprano which you need for nepomukcore which you need for kdepimlibs which you need for kdebase

{{Infobox tutorial|time=3 hours|type=HowTo|distribution=SUSE Linux 12.2|happyreaders=2|unhappyreaders=0}}

This describes how to use a virtual machine for building the latest KDE from sources.

= Virtual Machine Setup =
Create a virtual machine, e.g. using [http://www.linuxintro.org/wiki/VirtualbOx VirtualBox]. Regarding harddisk: KDE 4 fits into 10 GB, however [[User:Tstaerk|I]] recommend 40GB, one partition. Regarding RAM: You will need at least 1GB ram for the virtual machine, of course more is better.

;You will need to set your SUSE CD as your virtual machine's cdrom.

== setup for SSH ==
To be able to log in to your VM using ssh, stop and disable the firewall:
rcSuSEfirewall2 stop
chkconfig SuSEfirewall2_setup off
chkconfig SuSEfirewall2_init off
/etc/init.d/sshd start
chkconfig sshd on
Inside the VM, install some needed packages:
yast -i libqt4-devel pcre-devel libxslt-devel libxml2-devel docbook-xsl-stylesheets git cmake \
libdbusmenu-qt-devel giflib-devel strigi-devel libQtWebKit-devel libqimageblitz-devel libical-devel libgpgme-devel \
boost-devel libqjson-devel cyrus-sasl-devel libiodbc-devel

;Now it is time to do a snapshot or clone from your VM.
You will be able to return to this machine state whenever you want.

== a few more steps ==
[http://www.linuxintro.org/wiki/open_a_console Open a console] as root
su -

== on an x64 distribution ==
If and only if you have a /lib64 path, you are on an x64 distribution.
Make sure you have the needed environment variables and alias set by having a file /root/.bashrc.
cd
cat >.bashrc<<EOF
export KDEDIR=/usr/local
alias cmakekde="cmake . -DCMAKE_INSTALL_PREFIX=\$KDEDIR -DLIB_SUFFIX=64 -D[[Development/CMake/Addons_for_KDE#Buildtypes|CMAKE_BUILD_TYPE]]=debugfull && make -j8 && make install"
alias cmakekdelibs="cmake ../kdelibs -DCMAKE_INSTALL_PREFIX=\$KDEDIR -DLIB_SUFFIX=64 -DCMAKE_BUILD_TYPE=debugfull && make -j8 && make install"
alias makeqt="./configure -dbus -openssl -plugin-sql-mysql -libdir /usr/lib64 -prefix /usr && make -j8 && make install"
export QTDIR=/usr
EOF
cat >.gitconfig<<EOF
[url "git://anongit.kde.org/"]
insteadOf = kde:
[url "ssh://git@git.kde.org/"]
pushInsteadOf = kde:
EOF
Now activate this file
. /root/.bashrc

== on another distribution (incl 32bit)==
Make sure you have the needed environment variables and alias set by having a file /root/.bashrc.
cd
cat >.bashrc<<EOF
export KDEDIR=/usr/local
alias cmakekde="cmake . -DCMAKE_INSTALL_PREFIX=\$KDEDIR -DCMAKE_BUILD_TYPE=debugfull && make -j8 && make install"
alias cmakekdelibs="cmake ../kdelibs -DCMAKE_INSTALL_PREFIX=\$KDEDIR -DCMAKE_BUILD_TYPE=debugfull && make -j8 && make install"
alias makeqt="./configure -dbus -openssl -plugin-sql-mysql -prefix /usr && make -j8 && make install"
export QTDIR=/usr
EOF
cat >.gitconfig<<EOF
[url "git://anongit.kde.org/"]
insteadOf = kde:
[url "ssh://git@git.kde.org/"]
pushInsteadOf = kde:
EOF
Now activate this file
. /root/.bashrc

= Aquire and Build KDE as root =
If something fails you may need to make clean.

== cmake ==
Install the latest version of cmake:
cd
wget http://www.cmake.org/files/v2.8/cmake-2.8.10.2.tar.gz
tar xvzf cmake-2.8.10.2.tar.gz
cd cmake-2.8.10.2
./configure && make -j4 && make install

== automoc ==
automoc is needed for akonadi.
cd
git clone kde:automoc
cd automoc
cmakekde

== akonadi ==
Akonadi keeps personal information management data in a mysql database. It is needed for KDEPIMLIBS.
cd
git clone kde:akonadi
cd akonadi
cmakekde

== libattica ==
cd
git clone kde:attica
cd attica
cmakekde

== shared desktop ontologies ==
shared desktop ontologies is needed by kdepimlibs in order to build Nepomuk (which is a part of kdelibs)
cd
wget http://downloads.sourceforge.net/project/oscaf/shared-desktop-ontologies/0.10.0/shared-desktop-ontologies-0.10.0.tar.bz2
tar xvjf shared-desktop-ontologies-0.10.0.tar.bz2
cd shared-desktop-ontologies-0.10.0/
cmake . && make && make install

== soprano ==
cd
git clone kde:soprano
cd soprano
cmakekde

== phonon ==
Phonon is needed for kdebase-runtime
cd
git clone kde:phonon
cd phonon
cmakekde

== kdelibs ==
KDELIBS requires an out-of-source build, that is why it is more complicated to build:
cd
git clone kde:kdelibs
mkdir kdelibs-build
cd kdelibs-build
cmakekdelibs
Verify it has been correctly installed - the following must be possible:
kde4-config --prefix
/usr/local

== nepomuk-core ==
cd
git clone kde:nepomuk-core
cd nepomuk-core
cmakekde

== kdepimlibs ==
kdepimlibs is needed for kde-runtime.
cd
git clone kde:kdepimlibs
cd kdepimlibs
cmakekde

== kactivities ==
kactivities is needed for kde-workspace.
cd
git clone kde:kactivities
cd kactivities
cmakekde

== kdebase ==
cd
git clone kde:kde-baseapps
git clone kde:konsole
git clone kde:kde-workspace
git clone kde:kde-runtime
cd kde-baseapps
cmakekde
cd
cd konsole
cmakekde
cd
cd kde-workspace
cmakekde
cd
cd kde-runtime
cmakekde

Getting Started/Build/KDE4/on virtual machines

2013-01-26T18:44:01Z

Tstaerk: /* kdepimlibs */

{{Infobox tutorial|time=3 hours|type=HowTo|distribution=SUSE Linux 12.2|happyreaders=2|unhappyreaders=0}}

This describes how to use a virtual machine for building the latest KDE from sources.

= Virtual Machine Setup =
Create a virtual machine, e.g. using [http://www.linuxintro.org/wiki/VirtualbOx VirtualBox]. Regarding harddisk: KDE 4 fits into 10 GB, however [[User:Tstaerk|I]] recommend 40GB, one partition. Regarding RAM: You will need at least 1GB ram for the virtual machine, of course more is better.

;You will need to set your SUSE CD as your virtual machine's cdrom.

== setup for SSH ==
To be able to log in to your VM using ssh, stop and disable the firewall:
rcSuSEfirewall2 stop
chkconfig SuSEfirewall2_setup off
chkconfig SuSEfirewall2_init off
/etc/init.d/sshd start
chkconfig sshd on
Inside the VM, install some needed packages:
yast -i libqt4-devel pcre-devel libxslt-devel libxml2-devel docbook-xsl-stylesheets git cmake \
libdbusmenu-qt-devel giflib-devel strigi-devel libQtWebKit-devel libqimageblitz-devel libical-devel libgpgme-devel \
boost-devel libqjson-devel cyrus-sasl-devel

;Now it is time to do a snapshot or clone from your VM.
You will be able to return to this machine state whenever you want.

== a few more steps ==
[http://www.linuxintro.org/wiki/open_a_console Open a console] as root
su -

== on an x64 distribution ==
If and only if you have a /lib64 path, you are on an x64 distribution.
Make sure you have the needed environment variables and alias set by having a file /root/.bashrc.
cd
cat >.bashrc<<EOF
export KDEDIR=/usr/local
alias cmakekde="cmake . -DCMAKE_INSTALL_PREFIX=\$KDEDIR -DLIB_SUFFIX=64 -D[[Development/CMake/Addons_for_KDE#Buildtypes|CMAKE_BUILD_TYPE]]=debugfull && make -j8 && make install"
alias cmakekdelibs="cmake ../kdelibs -DCMAKE_INSTALL_PREFIX=\$KDEDIR -DLIB_SUFFIX=64 -DCMAKE_BUILD_TYPE=debugfull && make -j8 && make install"
alias makeqt="./configure -dbus -openssl -plugin-sql-mysql -libdir /usr/lib64 -prefix /usr && make -j8 && make install"
export QTDIR=/usr
EOF
cat >.gitconfig<<EOF
[url "git://anongit.kde.org/"]
insteadOf = kde:
[url "ssh://git@git.kde.org/"]
pushInsteadOf = kde:
EOF
Now activate this file
. /root/.bashrc

== on another distribution (incl 32bit)==
Make sure you have the needed environment variables and alias set by having a file /root/.bashrc.
cd
cat >.bashrc<<EOF
export KDEDIR=/usr/local
alias cmakekde="cmake . -DCMAKE_INSTALL_PREFIX=\$KDEDIR -DCMAKE_BUILD_TYPE=debugfull && make -j8 && make install"
alias cmakekdelibs="cmake ../kdelibs -DCMAKE_INSTALL_PREFIX=\$KDEDIR -DCMAKE_BUILD_TYPE=debugfull && make -j8 && make install"
alias makeqt="./configure -dbus -openssl -plugin-sql-mysql -prefix /usr && make -j8 && make install"
export QTDIR=/usr
EOF
cat >.gitconfig<<EOF
[url "git://anongit.kde.org/"]
insteadOf = kde:
[url "ssh://git@git.kde.org/"]
pushInsteadOf = kde:
EOF
Now activate this file
. /root/.bashrc

= Aquire and Build KDE as root =
If something fails you may need to make clean.

== cmake ==
Install the latest version of cmake:
cd
wget http://www.cmake.org/files/v2.8/cmake-2.8.10.2.tar.gz
tar xvzf cmake-2.8.10.2.tar.gz
cd cmake-2.8.10.2
./configure && make -j4 && make install

== automoc ==
automoc is needed for akonadi.
cd
git clone kde:automoc
cd automoc
cmakekde

== akonadi ==
Akonadi keeps personal information management data in a mysql database. It is needed for KDEPIMLIBS.
cd
git clone kde:akonadi
cd akonadi
cmakekde

== libattica ==
cd
git clone kde:attica
cd attica
cmakekde

== shared desktop ontologies ==
shared desktop ontologies is needed by kdepimlibs in order to build Nepomuk (which is a part of kdelibs)
cd
wget http://downloads.sourceforge.net/project/oscaf/shared-desktop-ontologies/0.10.0/shared-desktop-ontologies-0.10.0.tar.bz2
tar xvjf shared-desktop-ontologies-0.10.0.tar.bz2
cd shared-desktop-ontologies-0.10.0/
cmake . && make && make install

== soprano ==
cd
git clone kde:soprano
cd soprano
cmakekde

== phonon ==
Phonon is needed for kdebase-runtime
cd
git clone kde:phonon
cd phonon
cmakekde

== kdelibs ==
KDELIBS requires an out-of-source build, that is why it is more complicated to build:
cd
git clone kde:kdelibs
mkdir kdelibs-build
cd kdelibs-build
cmakekdelibs
Verify it has been correctly installed - the following must be possible:
kde4-config --prefix
/usr/local

== nepomuk-core ==
cd
git clone kde:nepomuk-core
cd nepomuk-core
cmakekde

== kdepimlibs ==
kdepimlibs is needed for kde-runtime.
cd
git clone kde:kdepimlibs
cd kdepimlibs
cmakekde

== kactivities ==
kactivities is needed for kde-workspace.
cd
git clone kde:kactivities
cd kactivities
cmakekde

== kdebase ==
cd
git clone kde:kde-baseapps
git clone kde:konsole
git clone kde:kde-workspace
git clone kde:kde-runtime
cd kde-baseapps
cmakekde
cd
cd konsole
cmakekde
cd
cd kde-workspace
cmakekde
cd
cd kde-runtime
cmakekde

Getting Started/Build/KDE4/on virtual machines

2013-01-26T17:58:37Z

Tstaerk: /* setup for SSH */

{{Infobox tutorial|time=3 hours|type=HowTo|distribution=SUSE Linux 12.2|happyreaders=2|unhappyreaders=0}}

This describes how to use a virtual machine for building the latest KDE from sources.

= Virtual Machine Setup =
Create a virtual machine, e.g. using [http://www.linuxintro.org/wiki/VirtualbOx VirtualBox]. Regarding harddisk: KDE 4 fits into 10 GB, however [[User:Tstaerk|I]] recommend 40GB, one partition. Regarding RAM: You will need at least 1GB ram for the virtual machine, of course more is better.

;You will need to set your SUSE CD as your virtual machine's cdrom.

== setup for SSH ==
To be able to log in to your VM using ssh, stop and disable the firewall:
rcSuSEfirewall2 stop
chkconfig SuSEfirewall2_setup off
chkconfig SuSEfirewall2_init off
/etc/init.d/sshd start
chkconfig sshd on
Inside the VM, install some needed packages:
yast -i libqt4-devel pcre-devel libxslt-devel libxml2-devel docbook-xsl-stylesheets git cmake \
libdbusmenu-qt-devel giflib-devel strigi-devel libQtWebKit-devel libqimageblitz-devel libical-devel libgpgme-devel \
boost-devel libqjson-devel cyrus-sasl-devel

;Now it is time to do a snapshot or clone from your VM.
You will be able to return to this machine state whenever you want.

== a few more steps ==
[http://www.linuxintro.org/wiki/open_a_console Open a console] as root
su -

== on an x64 distribution ==
If and only if you have a /lib64 path, you are on an x64 distribution.
Make sure you have the needed environment variables and alias set by having a file /root/.bashrc.
cd
cat >.bashrc<<EOF
export KDEDIR=/usr/local
alias cmakekde="cmake . -DCMAKE_INSTALL_PREFIX=\$KDEDIR -DLIB_SUFFIX=64 -D[[Development/CMake/Addons_for_KDE#Buildtypes|CMAKE_BUILD_TYPE]]=debugfull && make -j8 && make install"
alias cmakekdelibs="cmake ../kdelibs -DCMAKE_INSTALL_PREFIX=\$KDEDIR -DLIB_SUFFIX=64 -DCMAKE_BUILD_TYPE=debugfull && make -j8 && make install"
alias makeqt="./configure -dbus -openssl -plugin-sql-mysql -libdir /usr/lib64 -prefix /usr && make -j8 && make install"
export QTDIR=/usr
EOF
cat >.gitconfig<<EOF
[url "git://anongit.kde.org/"]
insteadOf = kde:
[url "ssh://git@git.kde.org/"]
pushInsteadOf = kde:
EOF
Now activate this file
. /root/.bashrc

== on another distribution (incl 32bit)==
Make sure you have the needed environment variables and alias set by having a file /root/.bashrc.
cd
cat >.bashrc<<EOF
export KDEDIR=/usr/local
alias cmakekde="cmake . -DCMAKE_INSTALL_PREFIX=\$KDEDIR -DCMAKE_BUILD_TYPE=debugfull && make -j8 && make install"
alias cmakekdelibs="cmake ../kdelibs -DCMAKE_INSTALL_PREFIX=\$KDEDIR -DCMAKE_BUILD_TYPE=debugfull && make -j8 && make install"
alias makeqt="./configure -dbus -openssl -plugin-sql-mysql -prefix /usr && make -j8 && make install"
export QTDIR=/usr
EOF
cat >.gitconfig<<EOF
[url "git://anongit.kde.org/"]
insteadOf = kde:
[url "ssh://git@git.kde.org/"]
pushInsteadOf = kde:
EOF
Now activate this file
. /root/.bashrc

= Aquire and Build KDE as root =
If something fails you may need to make clean.

== cmake ==
Install the latest version of cmake:
cd
wget http://www.cmake.org/files/v2.8/cmake-2.8.10.2.tar.gz
tar xvzf cmake-2.8.10.2.tar.gz
cd cmake-2.8.10.2
./configure && make -j4 && make install

== automoc ==
automoc is needed for akonadi.
cd
git clone kde:automoc
cd automoc
cmakekde

== akonadi ==
Akonadi keeps personal information management data in a mysql database. It is needed for KDEPIMLIBS.
cd
git clone kde:akonadi
cd akonadi
cmakekde

== libattica ==
cd
git clone kde:attica
cd attica
cmakekde

== shared desktop ontologies ==
shared desktop ontologies is needed by kdepimlibs in order to build Nepomuk (which is a part of kdelibs)
cd
wget http://downloads.sourceforge.net/project/oscaf/shared-desktop-ontologies/0.10.0/shared-desktop-ontologies-0.10.0.tar.bz2
tar xvjf shared-desktop-ontologies-0.10.0.tar.bz2
cd shared-desktop-ontologies-0.10.0/
cmake . && make && make install

== soprano ==
cd
git clone kde:soprano
cd soprano
cmakekde

== phonon ==
Phonon is needed for kdebase-runtime
cd
git clone kde:phonon
cd phonon
cmakekde

== kdelibs ==
KDELIBS requires an out-of-source build, that is why it is more complicated to build:
cd
git clone kde:kdelibs
mkdir kdelibs-build
cd kdelibs-build
cmakekdelibs
Verify it has been correctly installed - the following must be possible:
kde4-config --prefix
/usr/local

== kdepimlibs ==
kdepimlibs is needed for kde-runtime.
cd
git clone kde:kdepimlibs
cd kdepimlibs
cmakekde

== kactivities ==
kactivities is needed for kde-workspace.
cd
git clone kde:kactivities
cd kactivities
cmakekde

== kdebase ==
cd
git clone kde:kde-baseapps
git clone kde:konsole
git clone kde:kde-workspace
git clone kde:kde-runtime
cd kde-baseapps
cmakekde
cd
cd konsole
cmakekde
cd
cd kde-workspace
cmakekde
cd
cd kde-runtime
cmakekde

Getting Started/Build/KDE4/on virtual machines

2013-01-26T17:52:30Z

Tstaerk: /* phonon */

{{Infobox tutorial|time=3 hours|type=HowTo|distribution=SUSE Linux 12.2|happyreaders=2|unhappyreaders=0}}

This describes how to use a virtual machine for building the latest KDE from sources.

= Virtual Machine Setup =
Create a virtual machine, e.g. using [http://www.linuxintro.org/wiki/VirtualbOx VirtualBox]. Regarding harddisk: KDE 4 fits into 10 GB, however [[User:Tstaerk|I]] recommend 40GB, one partition. Regarding RAM: You will need at least 1GB ram for the virtual machine, of course more is better.

;You will need to set your SUSE CD as your virtual machine's cdrom.

== setup for SSH ==
To be able to log in to your VM using ssh, stop and disable the firewall:
rcSuSEfirewall2 stop
chkconfig SuSEfirewall2_setup off
chkconfig SuSEfirewall2_init off
/etc/init.d/sshd start
chkconfig sshd on
Inside the VM, install some needed packages:
yast -i libqt4-devel libsoprano-devel pcre-devel libxslt-devel libxml2-devel docbook-xsl-stylesheets git cmake \
libdbusmenu-qt-devel giflib-devel strigi-devel libQtWebKit-devel libqimageblitz-devel libical-devel libgpgme-devel \
boost-devel libqjson-devel cyrus-sasl-devel

;Now it is time to do a snapshot or clone from your VM.
You will be able to return to this machine state whenever you want.

== a few more steps ==
[http://www.linuxintro.org/wiki/open_a_console Open a console] as root
su -

== on an x64 distribution ==
If and only if you have a /lib64 path, you are on an x64 distribution.
Make sure you have the needed environment variables and alias set by having a file /root/.bashrc.
cd
cat >.bashrc<<EOF
export KDEDIR=/usr/local
alias cmakekde="cmake . -DCMAKE_INSTALL_PREFIX=\$KDEDIR -DLIB_SUFFIX=64 -D[[Development/CMake/Addons_for_KDE#Buildtypes|CMAKE_BUILD_TYPE]]=debugfull && make -j8 && make install"
alias cmakekdelibs="cmake ../kdelibs -DCMAKE_INSTALL_PREFIX=\$KDEDIR -DLIB_SUFFIX=64 -DCMAKE_BUILD_TYPE=debugfull && make -j8 && make install"
alias makeqt="./configure -dbus -openssl -plugin-sql-mysql -libdir /usr/lib64 -prefix /usr && make -j8 && make install"
export QTDIR=/usr
EOF
cat >.gitconfig<<EOF
[url "git://anongit.kde.org/"]
insteadOf = kde:
[url "ssh://git@git.kde.org/"]
pushInsteadOf = kde:
EOF
Now activate this file
. /root/.bashrc

== on another distribution (incl 32bit)==
Make sure you have the needed environment variables and alias set by having a file /root/.bashrc.
cd
cat >.bashrc<<EOF
export KDEDIR=/usr/local
alias cmakekde="cmake . -DCMAKE_INSTALL_PREFIX=\$KDEDIR -DCMAKE_BUILD_TYPE=debugfull && make -j8 && make install"
alias cmakekdelibs="cmake ../kdelibs -DCMAKE_INSTALL_PREFIX=\$KDEDIR -DCMAKE_BUILD_TYPE=debugfull && make -j8 && make install"
alias makeqt="./configure -dbus -openssl -plugin-sql-mysql -prefix /usr && make -j8 && make install"
export QTDIR=/usr
EOF
cat >.gitconfig<<EOF
[url "git://anongit.kde.org/"]
insteadOf = kde:
[url "ssh://git@git.kde.org/"]
pushInsteadOf = kde:
EOF
Now activate this file
. /root/.bashrc

= Aquire and Build KDE as root =
If something fails you may need to make clean.

== cmake ==
Install the latest version of cmake:
cd
wget http://www.cmake.org/files/v2.8/cmake-2.8.10.2.tar.gz
tar xvzf cmake-2.8.10.2.tar.gz
cd cmake-2.8.10.2
./configure && make -j4 && make install

== automoc ==
automoc is needed for akonadi.
cd
git clone kde:automoc
cd automoc
cmakekde

== akonadi ==
Akonadi keeps personal information management data in a mysql database. It is needed for KDEPIMLIBS.
cd
git clone kde:akonadi
cd akonadi
cmakekde

== libattica ==
cd
git clone kde:attica
cd attica
cmakekde

== shared desktop ontologies ==
shared desktop ontologies is needed by kdepimlibs in order to build Nepomuk (which is a part of kdelibs)
cd
wget http://downloads.sourceforge.net/project/oscaf/shared-desktop-ontologies/0.10.0/shared-desktop-ontologies-0.10.0.tar.bz2
tar xvjf shared-desktop-ontologies-0.10.0.tar.bz2
cd shared-desktop-ontologies-0.10.0/
cmake . && make && make install

== soprano ==
cd
git clone kde:soprano
cd soprano
cmakekde

== phonon ==
Phonon is needed for kdebase-runtime
cd
git clone kde:phonon
cd phonon
cmakekde

== kdelibs ==
KDELIBS requires an out-of-source build, that is why it is more complicated to build:
cd
git clone kde:kdelibs
mkdir kdelibs-build
cd kdelibs-build
cmakekdelibs
Verify it has been correctly installed - the following must be possible:
kde4-config --prefix
/usr/local

== kdepimlibs ==
kdepimlibs is needed for kde-runtime.
cd
git clone kde:kdepimlibs
cd kdepimlibs
cmakekde

== kactivities ==
kactivities is needed for kde-workspace.
cd
git clone kde:kactivities
cd kactivities
cmakekde

== kdebase ==
cd
git clone kde:kde-baseapps
git clone kde:konsole
git clone kde:kde-workspace
git clone kde:kde-runtime
cd kde-baseapps
cmakekde
cd
cd konsole
cmakekde
cd
cd kde-workspace
cmakekde
cd
cd kde-runtime
cmakekde

Getting Started/Build/KDE4/on virtual machines

2013-01-26T17:50:48Z

Tstaerk: /* shared desktop ontologies */

{{Infobox tutorial|time=3 hours|type=HowTo|distribution=SUSE Linux 12.2|happyreaders=2|unhappyreaders=0}}

This describes how to use a virtual machine for building the latest KDE from sources.

= Virtual Machine Setup =
Create a virtual machine, e.g. using [http://www.linuxintro.org/wiki/VirtualbOx VirtualBox]. Regarding harddisk: KDE 4 fits into 10 GB, however [[User:Tstaerk|I]] recommend 40GB, one partition. Regarding RAM: You will need at least 1GB ram for the virtual machine, of course more is better.

;You will need to set your SUSE CD as your virtual machine's cdrom.

== setup for SSH ==
To be able to log in to your VM using ssh, stop and disable the firewall:
rcSuSEfirewall2 stop
chkconfig SuSEfirewall2_setup off
chkconfig SuSEfirewall2_init off
/etc/init.d/sshd start
chkconfig sshd on
Inside the VM, install some needed packages:
yast -i libqt4-devel libsoprano-devel pcre-devel libxslt-devel libxml2-devel docbook-xsl-stylesheets git cmake \
libdbusmenu-qt-devel giflib-devel strigi-devel libQtWebKit-devel libqimageblitz-devel libical-devel libgpgme-devel \
boost-devel libqjson-devel cyrus-sasl-devel

;Now it is time to do a snapshot or clone from your VM.
You will be able to return to this machine state whenever you want.

== a few more steps ==
[http://www.linuxintro.org/wiki/open_a_console Open a console] as root
su -

== on an x64 distribution ==
If and only if you have a /lib64 path, you are on an x64 distribution.
Make sure you have the needed environment variables and alias set by having a file /root/.bashrc.
cd
cat >.bashrc<<EOF
export KDEDIR=/usr/local
alias cmakekde="cmake . -DCMAKE_INSTALL_PREFIX=\$KDEDIR -DLIB_SUFFIX=64 -D[[Development/CMake/Addons_for_KDE#Buildtypes|CMAKE_BUILD_TYPE]]=debugfull && make -j8 && make install"
alias cmakekdelibs="cmake ../kdelibs -DCMAKE_INSTALL_PREFIX=\$KDEDIR -DLIB_SUFFIX=64 -DCMAKE_BUILD_TYPE=debugfull && make -j8 && make install"
alias makeqt="./configure -dbus -openssl -plugin-sql-mysql -libdir /usr/lib64 -prefix /usr && make -j8 && make install"
export QTDIR=/usr
EOF
cat >.gitconfig<<EOF
[url "git://anongit.kde.org/"]
insteadOf = kde:
[url "ssh://git@git.kde.org/"]
pushInsteadOf = kde:
EOF
Now activate this file
. /root/.bashrc

== on another distribution (incl 32bit)==
Make sure you have the needed environment variables and alias set by having a file /root/.bashrc.
cd
cat >.bashrc<<EOF
export KDEDIR=/usr/local
alias cmakekde="cmake . -DCMAKE_INSTALL_PREFIX=\$KDEDIR -DCMAKE_BUILD_TYPE=debugfull && make -j8 && make install"
alias cmakekdelibs="cmake ../kdelibs -DCMAKE_INSTALL_PREFIX=\$KDEDIR -DCMAKE_BUILD_TYPE=debugfull && make -j8 && make install"
alias makeqt="./configure -dbus -openssl -plugin-sql-mysql -prefix /usr && make -j8 && make install"
export QTDIR=/usr
EOF
cat >.gitconfig<<EOF
[url "git://anongit.kde.org/"]
insteadOf = kde:
[url "ssh://git@git.kde.org/"]
pushInsteadOf = kde:
EOF
Now activate this file
. /root/.bashrc

= Aquire and Build KDE as root =
If something fails you may need to make clean.

== cmake ==
Install the latest version of cmake:
cd
wget http://www.cmake.org/files/v2.8/cmake-2.8.10.2.tar.gz
tar xvzf cmake-2.8.10.2.tar.gz
cd cmake-2.8.10.2
./configure && make -j4 && make install

== automoc ==
automoc is needed for akonadi.
cd
git clone kde:automoc
cd automoc
cmakekde

== akonadi ==
Akonadi keeps personal information management data in a mysql database. It is needed for KDEPIMLIBS.
cd
git clone kde:akonadi
cd akonadi
cmakekde

== libattica ==
cd
git clone kde:attica
cd attica
cmakekde

== shared desktop ontologies ==
shared desktop ontologies is needed by kdepimlibs in order to build Nepomuk (which is a part of kdelibs)
cd
wget http://downloads.sourceforge.net/project/oscaf/shared-desktop-ontologies/0.10.0/shared-desktop-ontologies-0.10.0.tar.bz2
tar xvjf shared-desktop-ontologies-0.10.0.tar.bz2
cd shared-desktop-ontologies-0.10.0/
cmake . && make && make install

== soprano ==
cd
git clone kde:soprano
cd soprano
cmakekde

== phonon ==
Phonon is needed for kdebase-runtime
cd
git clone git://anongit.kde.org/phonon
cd phonon
cmakekde

== kdelibs ==
KDELIBS requires an out-of-source build, that is why it is more complicated to build:
cd
git clone kde:kdelibs
mkdir kdelibs-build
cd kdelibs-build
cmakekdelibs
Verify it has been correctly installed - the following must be possible:
kde4-config --prefix
/usr/local

== kdepimlibs ==
kdepimlibs is needed for kde-runtime.
cd
git clone kde:kdepimlibs
cd kdepimlibs
cmakekde

== kactivities ==
kactivities is needed for kde-workspace.
cd
git clone kde:kactivities
cd kactivities
cmakekde

== kdebase ==
cd
git clone kde:kde-baseapps
git clone kde:konsole
git clone kde:kde-workspace
git clone kde:kde-runtime
cd kde-baseapps
cmakekde
cd
cd konsole
cmakekde
cd
cd kde-workspace
cmakekde
cd
cd kde-runtime
cmakekde

Getting Started/Build/KDE4/on virtual machines

2013-01-26T17:49:11Z

Tstaerk: /* setup for SSH */

{{Infobox tutorial|time=3 hours|type=HowTo|distribution=SUSE Linux 12.2|happyreaders=2|unhappyreaders=0}}

This describes how to use a virtual machine for building the latest KDE from sources.

= Virtual Machine Setup =
Create a virtual machine, e.g. using [http://www.linuxintro.org/wiki/VirtualbOx VirtualBox]. Regarding harddisk: KDE 4 fits into 10 GB, however [[User:Tstaerk|I]] recommend 40GB, one partition. Regarding RAM: You will need at least 1GB ram for the virtual machine, of course more is better.

;You will need to set your SUSE CD as your virtual machine's cdrom.

== setup for SSH ==
To be able to log in to your VM using ssh, stop and disable the firewall:
rcSuSEfirewall2 stop
chkconfig SuSEfirewall2_setup off
chkconfig SuSEfirewall2_init off
/etc/init.d/sshd start
chkconfig sshd on
Inside the VM, install some needed packages:
yast -i libqt4-devel libsoprano-devel pcre-devel libxslt-devel libxml2-devel docbook-xsl-stylesheets git cmake \
libdbusmenu-qt-devel giflib-devel strigi-devel libQtWebKit-devel libqimageblitz-devel libical-devel libgpgme-devel \
boost-devel libqjson-devel cyrus-sasl-devel

;Now it is time to do a snapshot or clone from your VM.
You will be able to return to this machine state whenever you want.

== a few more steps ==
[http://www.linuxintro.org/wiki/open_a_console Open a console] as root
su -

== on an x64 distribution ==
If and only if you have a /lib64 path, you are on an x64 distribution.
Make sure you have the needed environment variables and alias set by having a file /root/.bashrc.
cd
cat >.bashrc<<EOF
export KDEDIR=/usr/local
alias cmakekde="cmake . -DCMAKE_INSTALL_PREFIX=\$KDEDIR -DLIB_SUFFIX=64 -D[[Development/CMake/Addons_for_KDE#Buildtypes|CMAKE_BUILD_TYPE]]=debugfull && make -j8 && make install"
alias cmakekdelibs="cmake ../kdelibs -DCMAKE_INSTALL_PREFIX=\$KDEDIR -DLIB_SUFFIX=64 -DCMAKE_BUILD_TYPE=debugfull && make -j8 && make install"
alias makeqt="./configure -dbus -openssl -plugin-sql-mysql -libdir /usr/lib64 -prefix /usr && make -j8 && make install"
export QTDIR=/usr
EOF
cat >.gitconfig<<EOF
[url "git://anongit.kde.org/"]
insteadOf = kde:
[url "ssh://git@git.kde.org/"]
pushInsteadOf = kde:
EOF
Now activate this file
. /root/.bashrc

== on another distribution (incl 32bit)==
Make sure you have the needed environment variables and alias set by having a file /root/.bashrc.
cd
cat >.bashrc<<EOF
export KDEDIR=/usr/local
alias cmakekde="cmake . -DCMAKE_INSTALL_PREFIX=\$KDEDIR -DCMAKE_BUILD_TYPE=debugfull && make -j8 && make install"
alias cmakekdelibs="cmake ../kdelibs -DCMAKE_INSTALL_PREFIX=\$KDEDIR -DCMAKE_BUILD_TYPE=debugfull && make -j8 && make install"
alias makeqt="./configure -dbus -openssl -plugin-sql-mysql -prefix /usr && make -j8 && make install"
export QTDIR=/usr
EOF
cat >.gitconfig<<EOF
[url "git://anongit.kde.org/"]
insteadOf = kde:
[url "ssh://git@git.kde.org/"]
pushInsteadOf = kde:
EOF
Now activate this file
. /root/.bashrc

= Aquire and Build KDE as root =
If something fails you may need to make clean.

== cmake ==
Install the latest version of cmake:
cd
wget http://www.cmake.org/files/v2.8/cmake-2.8.10.2.tar.gz
tar xvzf cmake-2.8.10.2.tar.gz
cd cmake-2.8.10.2
./configure && make -j4 && make install

== automoc ==
automoc is needed for akonadi.
cd
git clone kde:automoc
cd automoc
cmakekde

== akonadi ==
Akonadi keeps personal information management data in a mysql database. It is needed for KDEPIMLIBS.
cd
git clone kde:akonadi
cd akonadi
cmakekde

== libattica ==
cd
git clone kde:attica
cd attica
cmakekde

== shared desktop ontologies ==
shared desktop ontologies is needed by kdepimlibs in order to build Nepomuk (which is a part of kdelibs)
cd
wget http://downloads.sourceforge.net/project/oscaf/shared-desktop-ontologies/0.10.0/shared-desktop-ontologies-0.10.0.tar.bz2
tar xvjf shared-desktop-ontologies-0.10.0.tar.bz2
cd shared-desktop-ontologies-0.10.0/
cmake . && make && make install

== phonon ==
Phonon is needed for kdebase-runtime
cd
git clone git://anongit.kde.org/phonon
cd phonon
cmakekde

== kdelibs ==
KDELIBS requires an out-of-source build, that is why it is more complicated to build:
cd
git clone kde:kdelibs
mkdir kdelibs-build
cd kdelibs-build
cmakekdelibs
Verify it has been correctly installed - the following must be possible:
kde4-config --prefix
/usr/local

== kdepimlibs ==
kdepimlibs is needed for kde-runtime.
cd
git clone kde:kdepimlibs
cd kdepimlibs
cmakekde

== kactivities ==
kactivities is needed for kde-workspace.
cd
git clone kde:kactivities
cd kactivities
cmakekde

== kdebase ==
cd
git clone kde:kde-baseapps
git clone kde:konsole
git clone kde:kde-workspace
git clone kde:kde-runtime
cd kde-baseapps
cmakekde
cd
cd konsole
cmakekde
cd
cd kde-workspace
cmakekde
cd
cd kde-runtime
cmakekde

Getting Started/Build/KDE4/on virtual machines

2013-01-26T17:47:10Z

Tstaerk: /* setup for SSH */

{{Infobox tutorial|time=3 hours|type=HowTo|distribution=SUSE Linux 12.2|happyreaders=2|unhappyreaders=0}}

This describes how to use a virtual machine for building the latest KDE from sources.

= Virtual Machine Setup =
Create a virtual machine, e.g. using [http://www.linuxintro.org/wiki/VirtualbOx VirtualBox]. Regarding harddisk: KDE 4 fits into 10 GB, however [[User:Tstaerk|I]] recommend 40GB, one partition. Regarding RAM: You will need at least 1GB ram for the virtual machine, of course more is better.

;You will need to set your SUSE CD as your virtual machine's cdrom.

== setup for SSH ==
To be able to log in to your VM using ssh, stop and disable the firewall:
rcSuSEfirewall2 stop
chkconfig SuSEfirewall2_setup off
chkconfig SuSEfirewall2_init off
/etc/init.d/sshd start
chkconfig sshd on
Inside the VM, install some needed packages:
yast -i libqt4-devel libsoprano-devel pcre-devel libxslt-devel libxml2-devel docbook-xsl-stylesheets git cmake \
libdbusmenu-qt-devel giflib-devel strigi-devel libQtWebKit-devel libqimageblitz-devel libical-devel libgpgme-devel \
boost-devel libqjson-devel

;Now it is time to do a snapshot or clone from your VM.
You will be able to return to this machine state whenever you want.

== a few more steps ==
[http://www.linuxintro.org/wiki/open_a_console Open a console] as root
su -

== on an x64 distribution ==
If and only if you have a /lib64 path, you are on an x64 distribution.
Make sure you have the needed environment variables and alias set by having a file /root/.bashrc.
cd
cat >.bashrc<<EOF
export KDEDIR=/usr/local
alias cmakekde="cmake . -DCMAKE_INSTALL_PREFIX=\$KDEDIR -DLIB_SUFFIX=64 -D[[Development/CMake/Addons_for_KDE#Buildtypes|CMAKE_BUILD_TYPE]]=debugfull && make -j8 && make install"
alias cmakekdelibs="cmake ../kdelibs -DCMAKE_INSTALL_PREFIX=\$KDEDIR -DLIB_SUFFIX=64 -DCMAKE_BUILD_TYPE=debugfull && make -j8 && make install"
alias makeqt="./configure -dbus -openssl -plugin-sql-mysql -libdir /usr/lib64 -prefix /usr && make -j8 && make install"
export QTDIR=/usr
EOF
cat >.gitconfig<<EOF
[url "git://anongit.kde.org/"]
insteadOf = kde:
[url "ssh://git@git.kde.org/"]
pushInsteadOf = kde:
EOF
Now activate this file
. /root/.bashrc

== on another distribution (incl 32bit)==
Make sure you have the needed environment variables and alias set by having a file /root/.bashrc.
cd
cat >.bashrc<<EOF
export KDEDIR=/usr/local
alias cmakekde="cmake . -DCMAKE_INSTALL_PREFIX=\$KDEDIR -DCMAKE_BUILD_TYPE=debugfull && make -j8 && make install"
alias cmakekdelibs="cmake ../kdelibs -DCMAKE_INSTALL_PREFIX=\$KDEDIR -DCMAKE_BUILD_TYPE=debugfull && make -j8 && make install"
alias makeqt="./configure -dbus -openssl -plugin-sql-mysql -prefix /usr && make -j8 && make install"
export QTDIR=/usr
EOF
cat >.gitconfig<<EOF
[url "git://anongit.kde.org/"]
insteadOf = kde:
[url "ssh://git@git.kde.org/"]
pushInsteadOf = kde:
EOF
Now activate this file
. /root/.bashrc

= Aquire and Build KDE as root =
If something fails you may need to make clean.

== cmake ==
Install the latest version of cmake:
cd
wget http://www.cmake.org/files/v2.8/cmake-2.8.10.2.tar.gz
tar xvzf cmake-2.8.10.2.tar.gz
cd cmake-2.8.10.2
./configure && make -j4 && make install

== automoc ==
automoc is needed for akonadi.
cd
git clone kde:automoc
cd automoc
cmakekde

== akonadi ==
Akonadi keeps personal information management data in a mysql database. It is needed for KDEPIMLIBS.
cd
git clone kde:akonadi
cd akonadi
cmakekde

== libattica ==
cd
git clone kde:attica
cd attica
cmakekde

== shared desktop ontologies ==
shared desktop ontologies is needed by kdepimlibs in order to build Nepomuk (which is a part of kdelibs)
cd
wget http://downloads.sourceforge.net/project/oscaf/shared-desktop-ontologies/0.10.0/shared-desktop-ontologies-0.10.0.tar.bz2
tar xvjf shared-desktop-ontologies-0.10.0.tar.bz2
cd shared-desktop-ontologies-0.10.0/
cmake . && make && make install

== phonon ==
Phonon is needed for kdebase-runtime
cd
git clone git://anongit.kde.org/phonon
cd phonon
cmakekde

== kdelibs ==
KDELIBS requires an out-of-source build, that is why it is more complicated to build:
cd
git clone kde:kdelibs
mkdir kdelibs-build
cd kdelibs-build
cmakekdelibs
Verify it has been correctly installed - the following must be possible:
kde4-config --prefix
/usr/local

== kdepimlibs ==
kdepimlibs is needed for kde-runtime.
cd
git clone kde:kdepimlibs
cd kdepimlibs
cmakekde

== kactivities ==
kactivities is needed for kde-workspace.
cd
git clone kde:kactivities
cd kactivities
cmakekde

== kdebase ==
cd
git clone kde:kde-baseapps
git clone kde:konsole
git clone kde:kde-workspace
git clone kde:kde-runtime
cd kde-baseapps
cmakekde
cd
cd konsole
cmakekde
cd
cd kde-workspace
cmakekde
cd
cd kde-runtime
cmakekde

Getting Started/Build/KDE4/on virtual machines

2013-01-26T17:40:01Z

Tstaerk: /* shared desktop ontologies */

{{Infobox tutorial|time=3 hours|type=HowTo|distribution=SUSE Linux 12.2|happyreaders=2|unhappyreaders=0}}

This describes how to use a virtual machine for building the latest KDE from sources.

= Virtual Machine Setup =
Create a virtual machine, e.g. using [http://www.linuxintro.org/wiki/VirtualbOx VirtualBox]. Regarding harddisk: KDE 4 fits into 10 GB, however [[User:Tstaerk|I]] recommend 40GB, one partition. Regarding RAM: You will need at least 1GB ram for the virtual machine, of course more is better.

;You will need to set your SUSE CD as your virtual machine's cdrom.

== setup for SSH ==
To be able to log in to your VM using ssh, stop and disable the firewall:
rcSuSEfirewall2 stop
chkconfig SuSEfirewall2_setup off
chkconfig SuSEfirewall2_init off
/etc/init.d/sshd start
chkconfig sshd on
Inside the VM, install some needed packages:
yast -i libqt4-devel libsoprano-devel pcre-devel libxslt-devel libxml2-devel docbook-xsl-stylesheets git cmake \
libdbusmenu-qt-devel giflib-devel strigi-devel libQtWebKit-devel libqimageblitz-devel libical-devel libgpgme-devel \
boost-devel

;Now it is time to do a snapshot or clone from your VM.
You will be able to return to this machine state whenever you want.

== a few more steps ==
[http://www.linuxintro.org/wiki/open_a_console Open a console] as root
su -

== on an x64 distribution ==
If and only if you have a /lib64 path, you are on an x64 distribution.
Make sure you have the needed environment variables and alias set by having a file /root/.bashrc.
cd
cat >.bashrc<<EOF
export KDEDIR=/usr/local
alias cmakekde="cmake . -DCMAKE_INSTALL_PREFIX=\$KDEDIR -DLIB_SUFFIX=64 -D[[Development/CMake/Addons_for_KDE#Buildtypes|CMAKE_BUILD_TYPE]]=debugfull && make -j8 && make install"
alias cmakekdelibs="cmake ../kdelibs -DCMAKE_INSTALL_PREFIX=\$KDEDIR -DLIB_SUFFIX=64 -DCMAKE_BUILD_TYPE=debugfull && make -j8 && make install"
alias makeqt="./configure -dbus -openssl -plugin-sql-mysql -libdir /usr/lib64 -prefix /usr && make -j8 && make install"
export QTDIR=/usr
EOF
cat >.gitconfig<<EOF
[url "git://anongit.kde.org/"]
insteadOf = kde:
[url "ssh://git@git.kde.org/"]
pushInsteadOf = kde:
EOF
Now activate this file
. /root/.bashrc

== on another distribution (incl 32bit)==
Make sure you have the needed environment variables and alias set by having a file /root/.bashrc.
cd
cat >.bashrc<<EOF
export KDEDIR=/usr/local
alias cmakekde="cmake . -DCMAKE_INSTALL_PREFIX=\$KDEDIR -DCMAKE_BUILD_TYPE=debugfull && make -j8 && make install"
alias cmakekdelibs="cmake ../kdelibs -DCMAKE_INSTALL_PREFIX=\$KDEDIR -DCMAKE_BUILD_TYPE=debugfull && make -j8 && make install"
alias makeqt="./configure -dbus -openssl -plugin-sql-mysql -prefix /usr && make -j8 && make install"
export QTDIR=/usr
EOF
cat >.gitconfig<<EOF
[url "git://anongit.kde.org/"]
insteadOf = kde:
[url "ssh://git@git.kde.org/"]
pushInsteadOf = kde:
EOF
Now activate this file
. /root/.bashrc

= Aquire and Build KDE as root =
If something fails you may need to make clean.

== cmake ==
Install the latest version of cmake:
cd
wget http://www.cmake.org/files/v2.8/cmake-2.8.10.2.tar.gz
tar xvzf cmake-2.8.10.2.tar.gz
cd cmake-2.8.10.2
./configure && make -j4 && make install

== automoc ==
automoc is needed for akonadi.
cd
git clone kde:automoc
cd automoc
cmakekde

== akonadi ==
Akonadi keeps personal information management data in a mysql database. It is needed for KDEPIMLIBS.
cd
git clone kde:akonadi
cd akonadi
cmakekde

== libattica ==
cd
git clone kde:attica
cd attica
cmakekde

== shared desktop ontologies ==
shared desktop ontologies is needed by kdepimlibs in order to build Nepomuk (which is a part of kdelibs)
cd
wget http://downloads.sourceforge.net/project/oscaf/shared-desktop-ontologies/0.10.0/shared-desktop-ontologies-0.10.0.tar.bz2
tar xvjf shared-desktop-ontologies-0.10.0.tar.bz2
cd shared-desktop-ontologies-0.10.0/
cmake . && make && make install

== phonon ==
Phonon is needed for kdebase-runtime
cd
git clone git://anongit.kde.org/phonon
cd phonon
cmakekde

== kdelibs ==
KDELIBS requires an out-of-source build, that is why it is more complicated to build:
cd
git clone kde:kdelibs
mkdir kdelibs-build
cd kdelibs-build
cmakekdelibs
Verify it has been correctly installed - the following must be possible:
kde4-config --prefix
/usr/local

== kdepimlibs ==
kdepimlibs is needed for kde-runtime.
cd
git clone kde:kdepimlibs
cd kdepimlibs
cmakekde

== kactivities ==
kactivities is needed for kde-workspace.
cd
git clone kde:kactivities
cd kactivities
cmakekde

== kdebase ==
cd
git clone kde:kde-baseapps
git clone kde:konsole
git clone kde:kde-workspace
git clone kde:kde-runtime
cd kde-baseapps
cmakekde
cd
cd konsole
cmakekde
cd
cd kde-workspace
cmakekde
cd
cd kde-runtime
cmakekde

Getting Started/Build/KDE4/on virtual machines

2013-01-26T17:39:10Z

Tstaerk: /* shared desktop ontologies */

{{Infobox tutorial|time=3 hours|type=HowTo|distribution=SUSE Linux 12.2|happyreaders=2|unhappyreaders=0}}

This describes how to use a virtual machine for building the latest KDE from sources.

= Virtual Machine Setup =
Create a virtual machine, e.g. using [http://www.linuxintro.org/wiki/VirtualbOx VirtualBox]. Regarding harddisk: KDE 4 fits into 10 GB, however [[User:Tstaerk|I]] recommend 40GB, one partition. Regarding RAM: You will need at least 1GB ram for the virtual machine, of course more is better.

;You will need to set your SUSE CD as your virtual machine's cdrom.

== setup for SSH ==
To be able to log in to your VM using ssh, stop and disable the firewall:
rcSuSEfirewall2 stop
chkconfig SuSEfirewall2_setup off
chkconfig SuSEfirewall2_init off
/etc/init.d/sshd start
chkconfig sshd on
Inside the VM, install some needed packages:
yast -i libqt4-devel libsoprano-devel pcre-devel libxslt-devel libxml2-devel docbook-xsl-stylesheets git cmake \
libdbusmenu-qt-devel giflib-devel strigi-devel libQtWebKit-devel libqimageblitz-devel libical-devel libgpgme-devel \
boost-devel

;Now it is time to do a snapshot or clone from your VM.
You will be able to return to this machine state whenever you want.

== a few more steps ==
[http://www.linuxintro.org/wiki/open_a_console Open a console] as root
su -

== on an x64 distribution ==
If and only if you have a /lib64 path, you are on an x64 distribution.
Make sure you have the needed environment variables and alias set by having a file /root/.bashrc.
cd
cat >.bashrc<<EOF
export KDEDIR=/usr/local
alias cmakekde="cmake . -DCMAKE_INSTALL_PREFIX=\$KDEDIR -DLIB_SUFFIX=64 -D[[Development/CMake/Addons_for_KDE#Buildtypes|CMAKE_BUILD_TYPE]]=debugfull && make -j8 && make install"
alias cmakekdelibs="cmake ../kdelibs -DCMAKE_INSTALL_PREFIX=\$KDEDIR -DLIB_SUFFIX=64 -DCMAKE_BUILD_TYPE=debugfull && make -j8 && make install"
alias makeqt="./configure -dbus -openssl -plugin-sql-mysql -libdir /usr/lib64 -prefix /usr && make -j8 && make install"
export QTDIR=/usr
EOF
cat >.gitconfig<<EOF
[url "git://anongit.kde.org/"]
insteadOf = kde:
[url "ssh://git@git.kde.org/"]
pushInsteadOf = kde:
EOF
Now activate this file
. /root/.bashrc

== on another distribution (incl 32bit)==
Make sure you have the needed environment variables and alias set by having a file /root/.bashrc.
cd
cat >.bashrc<<EOF
export KDEDIR=/usr/local
alias cmakekde="cmake . -DCMAKE_INSTALL_PREFIX=\$KDEDIR -DCMAKE_BUILD_TYPE=debugfull && make -j8 && make install"
alias cmakekdelibs="cmake ../kdelibs -DCMAKE_INSTALL_PREFIX=\$KDEDIR -DCMAKE_BUILD_TYPE=debugfull && make -j8 && make install"
alias makeqt="./configure -dbus -openssl -plugin-sql-mysql -prefix /usr && make -j8 && make install"
export QTDIR=/usr
EOF
cat >.gitconfig<<EOF
[url "git://anongit.kde.org/"]
insteadOf = kde:
[url "ssh://git@git.kde.org/"]
pushInsteadOf = kde:
EOF
Now activate this file
. /root/.bashrc

= Aquire and Build KDE as root =
If something fails you may need to make clean.

== cmake ==
Install the latest version of cmake:
cd
wget http://www.cmake.org/files/v2.8/cmake-2.8.10.2.tar.gz
tar xvzf cmake-2.8.10.2.tar.gz
cd cmake-2.8.10.2
./configure && make -j4 && make install

== automoc ==
automoc is needed for akonadi.
cd
git clone kde:automoc
cd automoc
cmakekde

== akonadi ==
Akonadi keeps personal information management data in a mysql database. It is needed for KDEPIMLIBS.
cd
git clone kde:akonadi
cd akonadi
cmakekde

== libattica ==
cd
git clone kde:attica
cd attica
cmakekde

== shared desktop ontologies ==
shared desktop ontologies is needed by kdepimlibs in order to build Nepomuk (which is a part of kdelibs)
cd
wget http://downloads.sourceforge.net/project/oscaf/shared-desktop-ontologies/0.10.0/shared-desktop-ontologies-0.10.0.tar.bz2
bunzip2 shared-desktop-ontologies-0.10.0.tar.bz2
tar xvf shared-desktop-ontologies-0.10.0.tar
cd shared-desktop-ontologies-0.10.0/
cmake . && make && make install

== phonon ==
Phonon is needed for kdebase-runtime
cd
git clone git://anongit.kde.org/phonon
cd phonon
cmakekde

== kdelibs ==
KDELIBS requires an out-of-source build, that is why it is more complicated to build:
cd
git clone kde:kdelibs
mkdir kdelibs-build
cd kdelibs-build
cmakekdelibs
Verify it has been correctly installed - the following must be possible:
kde4-config --prefix
/usr/local

== kdepimlibs ==
kdepimlibs is needed for kde-runtime.
cd
git clone kde:kdepimlibs
cd kdepimlibs
cmakekde

== kactivities ==
kactivities is needed for kde-workspace.
cd
git clone kde:kactivities
cd kactivities
cmakekde

== kdebase ==
cd
git clone kde:kde-baseapps
git clone kde:konsole
git clone kde:kde-workspace
git clone kde:kde-runtime
cd kde-baseapps
cmakekde
cd
cd konsole
cmakekde
cd
cd kde-workspace
cmakekde
cd
cd kde-runtime
cmakekde

Getting Started/Build/KDE4/on virtual machines

2013-01-26T15:24:58Z

Tstaerk: cMake

{{Infobox tutorial|time=3 hours|type=HowTo|distribution=SUSE Linux 12.2|happyreaders=2|unhappyreaders=0}}

This describes how to use a virtual machine for building the latest KDE from sources.

= Virtual Machine Setup =
Create a virtual machine, e.g. using [http://www.linuxintro.org/wiki/VirtualbOx VirtualBox]. Regarding harddisk: KDE 4 fits into 10 GB, however [[User:Tstaerk|I]] recommend 40GB, one partition. Regarding RAM: You will need at least 1GB ram for the virtual machine, of course more is better.

;You will need to set your SUSE CD as your virtual machine's cdrom.

== setup for SSH ==
To be able to log in to your VM using ssh, stop and disable the firewall:
rcSuSEfirewall2 stop
chkconfig SuSEfirewall2_setup off
chkconfig SuSEfirewall2_init off
/etc/init.d/sshd start
chkconfig sshd on
Inside the VM, install some needed packages:
yast -i libqt4-devel libsoprano-devel pcre-devel libxslt-devel libxml2-devel docbook-xsl-stylesheets git cmake \
libdbusmenu-qt-devel giflib-devel strigi-devel libQtWebKit-devel libqimageblitz-devel libical-devel libgpgme-devel \
boost-devel

;Now it is time to do a snapshot or clone from your VM.
You will be able to return to this machine state whenever you want.

== a few more steps ==
[http://www.linuxintro.org/wiki/open_a_console Open a console] as root
su -

== on an x64 distribution ==
If and only if you have a /lib64 path, you are on an x64 distribution.
Make sure you have the needed environment variables and alias set by having a file /root/.bashrc.
cd
cat >.bashrc<<EOF
export KDEDIR=/usr/local
alias cmakekde="cmake . -DCMAKE_INSTALL_PREFIX=\$KDEDIR -DLIB_SUFFIX=64 -D[[Development/CMake/Addons_for_KDE#Buildtypes|CMAKE_BUILD_TYPE]]=debugfull && make -j8 && make install"
alias cmakekdelibs="cmake ../kdelibs -DCMAKE_INSTALL_PREFIX=\$KDEDIR -DLIB_SUFFIX=64 -DCMAKE_BUILD_TYPE=debugfull && make -j8 && make install"
alias makeqt="./configure -dbus -openssl -plugin-sql-mysql -libdir /usr/lib64 -prefix /usr && make -j8 && make install"
export QTDIR=/usr
EOF
cat >.gitconfig<<EOF
[url "git://anongit.kde.org/"]
insteadOf = kde:
[url "ssh://git@git.kde.org/"]
pushInsteadOf = kde:
EOF
Now activate this file
. /root/.bashrc

== on another distribution (incl 32bit)==
Make sure you have the needed environment variables and alias set by having a file /root/.bashrc.
cd
cat >.bashrc<<EOF
export KDEDIR=/usr/local
alias cmakekde="cmake . -DCMAKE_INSTALL_PREFIX=\$KDEDIR -DCMAKE_BUILD_TYPE=debugfull && make -j8 && make install"
alias cmakekdelibs="cmake ../kdelibs -DCMAKE_INSTALL_PREFIX=\$KDEDIR -DCMAKE_BUILD_TYPE=debugfull && make -j8 && make install"
alias makeqt="./configure -dbus -openssl -plugin-sql-mysql -prefix /usr && make -j8 && make install"
export QTDIR=/usr
EOF
cat >.gitconfig<<EOF
[url "git://anongit.kde.org/"]
insteadOf = kde:
[url "ssh://git@git.kde.org/"]
pushInsteadOf = kde:
EOF
Now activate this file
. /root/.bashrc

= Aquire and Build KDE as root =
If something fails you may need to make clean.

== cmake ==
Install the latest version of cmake:
cd
wget http://www.cmake.org/files/v2.8/cmake-2.8.10.2.tar.gz
tar xvzf cmake-2.8.10.2.tar.gz
cd cmake-2.8.10.2
./configure && make -j4 && make install

== automoc ==
automoc is needed for akonadi.
cd
git clone kde:automoc
cd automoc
cmakekde

== akonadi ==
Akonadi keeps personal information management data in a mysql database. It is needed for KDEPIMLIBS.
cd
git clone kde:akonadi
cd akonadi
cmakekde

== libattica ==
cd
git clone kde:attica
cd attica
cmakekde

== shared desktop ontologies ==
shared desktop ontologies is needed by kdepimlibs in order to build Nepomuk (which is a part of kdelibs)
cd
wget http://downloads.sourceforge.net/project/oscaf/shared-desktop-ontologies/0.9/shared-desktop-ontologies-0.9.0.tar.bz2
bunzip2 shared-desktop-ontologies-0.9.0.tar.bz2
tar xvf shared-desktop-ontologies-0.9.0.tar
cd shared-desktop-ontologies-0.9.0/
cmake . && make && make install

== phonon ==
Phonon is needed for kdebase-runtime
cd
git clone git://anongit.kde.org/phonon
cd phonon
cmakekde

== kdelibs ==
KDELIBS requires an out-of-source build, that is why it is more complicated to build:
cd
git clone kde:kdelibs
mkdir kdelibs-build
cd kdelibs-build
cmakekdelibs
Verify it has been correctly installed - the following must be possible:
kde4-config --prefix
/usr/local

== kdepimlibs ==
kdepimlibs is needed for kde-runtime.
cd
git clone kde:kdepimlibs
cd kdepimlibs
cmakekde

== kactivities ==
kactivities is needed for kde-workspace.
cd
git clone kde:kactivities
cd kactivities
cmakekde

== kdebase ==
cd
git clone kde:kde-baseapps
git clone kde:konsole
git clone kde:kde-workspace
git clone kde:kde-runtime
cd kde-baseapps
cmakekde
cd
cd konsole
cmakekde
cd
cd kde-workspace
cmakekde
cd
cd kde-runtime
cmakekde

Getting Started/Build/KDE4/on virtual machines

2013-01-26T15:23:36Z

Tstaerk:

{{Infobox tutorial|time=3 hours|type=HowTo|distribution=SUSE Linux 12.2|happyreaders=2|unhappyreaders=0}}

This describes how to use a virtual machine for building the latest KDE from sources.

= Virtual Machine Setup =
Create a virtual machine, e.g. using [http://www.linuxintro.org/wiki/VirtualbOx VirtualBox]. Regarding harddisk: KDE 4 fits into 10 GB, however [[User:Tstaerk|I]] recommend 40GB, one partition. Regarding RAM: You will need at least 1GB ram for the virtual machine, of course more is better.

;You will need to set your SUSE CD as your virtual machine's cdrom.

== setup for SSH ==
To be able to log in to your VM using ssh, stop and disable the firewall:
rcSuSEfirewall2 stop
chkconfig SuSEfirewall2_setup off
chkconfig SuSEfirewall2_init off
/etc/init.d/sshd start
chkconfig sshd on
Inside the VM, install some needed packages:
yast -i libqt4-devel libsoprano-devel pcre-devel libxslt-devel libxml2-devel docbook-xsl-stylesheets git cmake \
libdbusmenu-qt-devel giflib-devel strigi-devel libQtWebKit-devel libqimageblitz-devel libical-devel libgpgme-devel \
boost-devel

;Now it is time to do a snapshot or clone from your VM.
You will be able to return to this machine state whenever you want.

== a few more steps ==
[http://www.linuxintro.org/wiki/open_a_console Open a console] as root
su -

== on an x64 distribution ==
If and only if you have a /lib64 path, you are on an x64 distribution.
Make sure you have the needed environment variables and alias set by having a file /root/.bashrc.
cd
cat >.bashrc<<EOF
export KDEDIR=/usr/local
alias cmakekde="cmake . -DCMAKE_INSTALL_PREFIX=\$KDEDIR -DLIB_SUFFIX=64 -D[[Development/CMake/Addons_for_KDE#Buildtypes|CMAKE_BUILD_TYPE]]=debugfull && make -j8 && make install"
alias cmakekdelibs="cmake ../kdelibs -DCMAKE_INSTALL_PREFIX=\$KDEDIR -DLIB_SUFFIX=64 -DCMAKE_BUILD_TYPE=debugfull && make -j8 && make install"
alias makeqt="./configure -dbus -openssl -plugin-sql-mysql -libdir /usr/lib64 -prefix /usr && make -j8 && make install"
export QTDIR=/usr
EOF
cat >.gitconfig<<EOF
[url "git://anongit.kde.org/"]
insteadOf = kde:
[url "ssh://git@git.kde.org/"]
pushInsteadOf = kde:
EOF
Now activate this file
. /root/.bashrc

== on another distribution (incl 32bit)==
Make sure you have the needed environment variables and alias set by having a file /root/.bashrc.
cd
cat >.bashrc<<EOF
export KDEDIR=/usr/local
alias cmakekde="cmake . -DCMAKE_INSTALL_PREFIX=\$KDEDIR -DCMAKE_BUILD_TYPE=debugfull && make -j8 && make install"
alias cmakekdelibs="cmake ../kdelibs -DCMAKE_INSTALL_PREFIX=\$KDEDIR -DCMAKE_BUILD_TYPE=debugfull && make -j8 && make install"
alias makeqt="./configure -dbus -openssl -plugin-sql-mysql -prefix /usr && make -j8 && make install"
export QTDIR=/usr
EOF
cat >.gitconfig<<EOF
[url "git://anongit.kde.org/"]
insteadOf = kde:
[url "ssh://git@git.kde.org/"]
pushInsteadOf = kde:
EOF
Now activate this file
. /root/.bashrc

= Aquire and Build KDE as root =
If something fails you may need to make clean.

== automoc ==
automoc is needed for akonadi.
cd
git clone kde:automoc
cd automoc
cmakekde

== akonadi ==
Akonadi keeps personal information management data in a mysql database. It is needed for KDEPIMLIBS.
cd
git clone kde:akonadi
cd akonadi
cmakekde

== libattica ==
cd
git clone kde:attica
cd attica
cmakekde

== shared desktop ontologies ==
shared desktop ontologies is needed by kdepimlibs in order to build Nepomuk (which is a part of kdelibs)
cd
wget http://downloads.sourceforge.net/project/oscaf/shared-desktop-ontologies/0.9/shared-desktop-ontologies-0.9.0.tar.bz2
bunzip2 shared-desktop-ontologies-0.9.0.tar.bz2
tar xvf shared-desktop-ontologies-0.9.0.tar
cd shared-desktop-ontologies-0.9.0/
cmake . && make && make install

== phonon ==
Phonon is needed for kdebase-runtime
cd
git clone git://anongit.kde.org/phonon
cd phonon
cmakekde

== kdelibs ==
KDELIBS requires an out-of-source build, that is why it is more complicated to build:
cd
git clone kde:kdelibs
mkdir kdelibs-build
cd kdelibs-build
cmakekdelibs
Verify it has been correctly installed - the following must be possible:
kde4-config --prefix
/usr/local

== kdepimlibs ==
kdepimlibs is needed for kde-runtime.
cd
git clone kde:kdepimlibs
cd kdepimlibs
cmakekde

== kactivities ==
kactivities is needed for kde-workspace.
cd
git clone kde:kactivities
cd kactivities
cmakekde

== kdebase ==
cd
git clone kde:kde-baseapps
git clone kde:konsole
git clone kde:kde-workspace
git clone kde:kde-runtime
cd kde-baseapps
cmakekde
cd
cd konsole
cmakekde
cd
cd kde-workspace
cmakekde
cd
cd kde-runtime
cmakekde

Getting Started/Build/KDE4/on virtual machines

2013-01-26T15:23:22Z

Tstaerk: /* Virtual Machine Setup */

{{Infobox tutorial|time=3 hours|type=HowTo|distribution=SUSE Linux 12.1|happyreaders=2|unhappyreaders=0}}

This describes how to use a virtual machine for building the latest KDE from sources.

= Virtual Machine Setup =
Create a virtual machine, e.g. using [http://www.linuxintro.org/wiki/VirtualbOx VirtualBox]. Regarding harddisk: KDE 4 fits into 10 GB, however [[User:Tstaerk|I]] recommend 40GB, one partition. Regarding RAM: You will need at least 1GB ram for the virtual machine, of course more is better.

;You will need to set your SUSE CD as your virtual machine's cdrom.

== setup for SSH ==
To be able to log in to your VM using ssh, stop and disable the firewall:
rcSuSEfirewall2 stop
chkconfig SuSEfirewall2_setup off
chkconfig SuSEfirewall2_init off
/etc/init.d/sshd start
chkconfig sshd on
Inside the VM, install some needed packages:
yast -i libqt4-devel libsoprano-devel pcre-devel libxslt-devel libxml2-devel docbook-xsl-stylesheets git cmake \
libdbusmenu-qt-devel giflib-devel strigi-devel libQtWebKit-devel libqimageblitz-devel libical-devel libgpgme-devel \
boost-devel

;Now it is time to do a snapshot or clone from your VM.
You will be able to return to this machine state whenever you want.

== a few more steps ==
[http://www.linuxintro.org/wiki/open_a_console Open a console] as root
su -

== on an x64 distribution ==
If and only if you have a /lib64 path, you are on an x64 distribution.
Make sure you have the needed environment variables and alias set by having a file /root/.bashrc.
cd
cat >.bashrc<<EOF
export KDEDIR=/usr/local
alias cmakekde="cmake . -DCMAKE_INSTALL_PREFIX=\$KDEDIR -DLIB_SUFFIX=64 -D[[Development/CMake/Addons_for_KDE#Buildtypes|CMAKE_BUILD_TYPE]]=debugfull && make -j8 && make install"
alias cmakekdelibs="cmake ../kdelibs -DCMAKE_INSTALL_PREFIX=\$KDEDIR -DLIB_SUFFIX=64 -DCMAKE_BUILD_TYPE=debugfull && make -j8 && make install"
alias makeqt="./configure -dbus -openssl -plugin-sql-mysql -libdir /usr/lib64 -prefix /usr && make -j8 && make install"
export QTDIR=/usr
EOF
cat >.gitconfig<<EOF
[url "git://anongit.kde.org/"]
insteadOf = kde:
[url "ssh://git@git.kde.org/"]
pushInsteadOf = kde:
EOF
Now activate this file
. /root/.bashrc

== on another distribution (incl 32bit)==
Make sure you have the needed environment variables and alias set by having a file /root/.bashrc.
cd
cat >.bashrc<<EOF
export KDEDIR=/usr/local
alias cmakekde="cmake . -DCMAKE_INSTALL_PREFIX=\$KDEDIR -DCMAKE_BUILD_TYPE=debugfull && make -j8 && make install"
alias cmakekdelibs="cmake ../kdelibs -DCMAKE_INSTALL_PREFIX=\$KDEDIR -DCMAKE_BUILD_TYPE=debugfull && make -j8 && make install"
alias makeqt="./configure -dbus -openssl -plugin-sql-mysql -prefix /usr && make -j8 && make install"
export QTDIR=/usr
EOF
cat >.gitconfig<<EOF
[url "git://anongit.kde.org/"]
insteadOf = kde:
[url "ssh://git@git.kde.org/"]
pushInsteadOf = kde:
EOF
Now activate this file
. /root/.bashrc

= Aquire and Build KDE as root =
If something fails you may need to make clean.

== automoc ==
automoc is needed for akonadi.
cd
git clone kde:automoc
cd automoc
cmakekde

== akonadi ==
Akonadi keeps personal information management data in a mysql database. It is needed for KDEPIMLIBS.
cd
git clone kde:akonadi
cd akonadi
cmakekde

== libattica ==
cd
git clone kde:attica
cd attica
cmakekde

== shared desktop ontologies ==
shared desktop ontologies is needed by kdepimlibs in order to build Nepomuk (which is a part of kdelibs)
cd
wget http://downloads.sourceforge.net/project/oscaf/shared-desktop-ontologies/0.9/shared-desktop-ontologies-0.9.0.tar.bz2
bunzip2 shared-desktop-ontologies-0.9.0.tar.bz2
tar xvf shared-desktop-ontologies-0.9.0.tar
cd shared-desktop-ontologies-0.9.0/
cmake . && make && make install

== phonon ==
Phonon is needed for kdebase-runtime
cd
git clone git://anongit.kde.org/phonon
cd phonon
cmakekde

== kdelibs ==
KDELIBS requires an out-of-source build, that is why it is more complicated to build:
cd
git clone kde:kdelibs
mkdir kdelibs-build
cd kdelibs-build
cmakekdelibs
Verify it has been correctly installed - the following must be possible:
kde4-config --prefix
/usr/local

== kdepimlibs ==
kdepimlibs is needed for kde-runtime.
cd
git clone kde:kdepimlibs
cd kdepimlibs
cmakekde

== kactivities ==
kactivities is needed for kde-workspace.
cd
git clone kde:kactivities
cd kactivities
cmakekde

== kdebase ==
cd
git clone kde:kde-baseapps
git clone kde:konsole
git clone kde:kde-workspace
git clone kde:kde-runtime
cd kde-baseapps
cmakekde
cd
cd konsole
cmakekde
cd
cd kde-workspace
cmakekde
cd
cd kde-runtime
cmakekde

Getting Started/Build/KDE4/on virtual machines

2013-01-26T15:08:13Z

Tstaerk: /* setup for SSH */

{{Infobox tutorial|time=3 hours|type=HowTo|distribution=SUSE Linux 12.1|happyreaders=2|unhappyreaders=0}}

This describes how to use a virtual machine for building the latest KDE from sources.

= Virtual Machine Setup =
Create a virtual machine, e.g. using [http://www.linuxintro.org/wiki/VMWare VMware Player]. Regarding harddisk: KDE 4 fits into 10 GB, however [[User:Tstaerk|I]] recommend 40GB, one partition. Regarding RAM: You will need at least 1GB ram for the virtual machine, of course more is better.

;You will need to set your SUSE CD as your virtual machine's cdrom.

== setup for SSH ==
To be able to log in to your VM using ssh, stop and disable the firewall:
rcSuSEfirewall2 stop
chkconfig SuSEfirewall2_setup off
chkconfig SuSEfirewall2_init off
/etc/init.d/sshd start
chkconfig sshd on
Inside the VM, install some needed packages:
yast -i libqt4-devel libsoprano-devel pcre-devel libxslt-devel libxml2-devel docbook-xsl-stylesheets git cmake \
libdbusmenu-qt-devel giflib-devel strigi-devel libQtWebKit-devel libqimageblitz-devel libical-devel libgpgme-devel \
boost-devel

;Now it is time to do a snapshot or clone from your VM.
You will be able to return to this machine state whenever you want.

== a few more steps ==
[http://www.linuxintro.org/wiki/open_a_console Open a console] as root
su -

== on an x64 distribution ==
If and only if you have a /lib64 path, you are on an x64 distribution.
Make sure you have the needed environment variables and alias set by having a file /root/.bashrc.
cd
cat >.bashrc<<EOF
export KDEDIR=/usr/local
alias cmakekde="cmake . -DCMAKE_INSTALL_PREFIX=\$KDEDIR -DLIB_SUFFIX=64 -D[[Development/CMake/Addons_for_KDE#Buildtypes|CMAKE_BUILD_TYPE]]=debugfull && make -j8 && make install"
alias cmakekdelibs="cmake ../kdelibs -DCMAKE_INSTALL_PREFIX=\$KDEDIR -DLIB_SUFFIX=64 -DCMAKE_BUILD_TYPE=debugfull && make -j8 && make install"
alias makeqt="./configure -dbus -openssl -plugin-sql-mysql -libdir /usr/lib64 -prefix /usr && make -j8 && make install"
export QTDIR=/usr
EOF
cat >.gitconfig<<EOF
[url "git://anongit.kde.org/"]
insteadOf = kde:
[url "ssh://git@git.kde.org/"]
pushInsteadOf = kde:
EOF
Now activate this file
. /root/.bashrc

== on another distribution (incl 32bit)==
Make sure you have the needed environment variables and alias set by having a file /root/.bashrc.
cd
cat >.bashrc<<EOF
export KDEDIR=/usr/local
alias cmakekde="cmake . -DCMAKE_INSTALL_PREFIX=\$KDEDIR -DCMAKE_BUILD_TYPE=debugfull && make -j8 && make install"
alias cmakekdelibs="cmake ../kdelibs -DCMAKE_INSTALL_PREFIX=\$KDEDIR -DCMAKE_BUILD_TYPE=debugfull && make -j8 && make install"
alias makeqt="./configure -dbus -openssl -plugin-sql-mysql -prefix /usr && make -j8 && make install"
export QTDIR=/usr
EOF
cat >.gitconfig<<EOF
[url "git://anongit.kde.org/"]
insteadOf = kde:
[url "ssh://git@git.kde.org/"]
pushInsteadOf = kde:
EOF
Now activate this file
. /root/.bashrc

= Aquire and Build KDE as root =
If something fails you may need to make clean.

== automoc ==
automoc is needed for akonadi.
cd
git clone kde:automoc
cd automoc
cmakekde

== akonadi ==
Akonadi keeps personal information management data in a mysql database. It is needed for KDEPIMLIBS.
cd
git clone kde:akonadi
cd akonadi
cmakekde

== libattica ==
cd
git clone kde:attica
cd attica
cmakekde

== shared desktop ontologies ==
shared desktop ontologies is needed by kdepimlibs in order to build Nepomuk (which is a part of kdelibs)
cd
wget http://downloads.sourceforge.net/project/oscaf/shared-desktop-ontologies/0.9/shared-desktop-ontologies-0.9.0.tar.bz2
bunzip2 shared-desktop-ontologies-0.9.0.tar.bz2
tar xvf shared-desktop-ontologies-0.9.0.tar
cd shared-desktop-ontologies-0.9.0/
cmake . && make && make install

== phonon ==
Phonon is needed for kdebase-runtime
cd
git clone git://anongit.kde.org/phonon
cd phonon
cmakekde

== kdelibs ==
KDELIBS requires an out-of-source build, that is why it is more complicated to build:
cd
git clone kde:kdelibs
mkdir kdelibs-build
cd kdelibs-build
cmakekdelibs
Verify it has been correctly installed - the following must be possible:
kde4-config --prefix
/usr/local

== kdepimlibs ==
kdepimlibs is needed for kde-runtime.
cd
git clone kde:kdepimlibs
cd kdepimlibs
cmakekde

== kactivities ==
kactivities is needed for kde-workspace.
cd
git clone kde:kactivities
cd kactivities
cmakekde

== kdebase ==
cd
git clone kde:kde-baseapps
git clone kde:konsole
git clone kde:kde-workspace
git clone kde:kde-runtime
cd kde-baseapps
cmakekde
cd
cd konsole
cmakekde
cd
cd kde-workspace
cmakekde
cd
cd kde-runtime
cmakekde

Getting Started/Build/KDE4/on virtual machines

2013-01-26T13:57:11Z

Tstaerk: /* a few more steps */

{{Infobox tutorial|time=3 hours|type=HowTo|distribution=SUSE Linux 12.1|happyreaders=2|unhappyreaders=0}}

This describes how to use a virtual machine for building the latest KDE from sources.

= Virtual Machine Setup =
Create a virtual machine, e.g. using [http://www.linuxintro.org/wiki/VMWare VMware Player]. Regarding harddisk: KDE 4 fits into 10 GB, however [[User:Tstaerk|I]] recommend 40GB, one partition. Regarding RAM: You will need at least 1GB ram for the virtual machine, of course more is better.

;You will need to set your SUSE CD as your virtual machine's cdrom.

== setup for SSH ==
To be able to log in to your VM using ssh, stop and disable the firewall:
rcSuSEfirewall2 stop
chkconfig SuSEfirewall2_setup off
chkconfig SuSEfirewall2_init off
/etc/init.d/sshd start
chkconfig sshd on
Inside the VM, install some needed packages:
yast -i libqt4-devel libsoprano-devel pcre-devel libxslt-devel libxml2-devel docbook-xsl-stylesheets git cmake \
libdbusmenu-qt-devel giflib-devel strigi-devel libQtWebKit-devel libqimageblitz-devel libical-devel libgpgme-devel

;Now it is time to do a snapshot or clone from your VM.
You will be able to return to this machine state whenever you want.

== a few more steps ==
[http://www.linuxintro.org/wiki/open_a_console Open a console] as root
su -

== on an x64 distribution ==
If and only if you have a /lib64 path, you are on an x64 distribution.
Make sure you have the needed environment variables and alias set by having a file /root/.bashrc.
cd
cat >.bashrc<<EOF
export KDEDIR=/usr/local
alias cmakekde="cmake . -DCMAKE_INSTALL_PREFIX=\$KDEDIR -DLIB_SUFFIX=64 -D[[Development/CMake/Addons_for_KDE#Buildtypes|CMAKE_BUILD_TYPE]]=debugfull && make -j8 && make install"
alias cmakekdelibs="cmake ../kdelibs -DCMAKE_INSTALL_PREFIX=\$KDEDIR -DLIB_SUFFIX=64 -DCMAKE_BUILD_TYPE=debugfull && make -j8 && make install"
alias makeqt="./configure -dbus -openssl -plugin-sql-mysql -libdir /usr/lib64 -prefix /usr && make -j8 && make install"
export QTDIR=/usr
EOF
cat >.gitconfig<<EOF
[url "git://anongit.kde.org/"]
insteadOf = kde:
[url "ssh://git@git.kde.org/"]
pushInsteadOf = kde:
EOF
Now activate this file
. /root/.bashrc

== on another distribution (incl 32bit)==
Make sure you have the needed environment variables and alias set by having a file /root/.bashrc.
cd
cat >.bashrc<<EOF
export KDEDIR=/usr/local
alias cmakekde="cmake . -DCMAKE_INSTALL_PREFIX=\$KDEDIR -DCMAKE_BUILD_TYPE=debugfull && make -j8 && make install"
alias cmakekdelibs="cmake ../kdelibs -DCMAKE_INSTALL_PREFIX=\$KDEDIR -DCMAKE_BUILD_TYPE=debugfull && make -j8 && make install"
alias makeqt="./configure -dbus -openssl -plugin-sql-mysql -prefix /usr && make -j8 && make install"
export QTDIR=/usr
EOF
cat >.gitconfig<<EOF
[url "git://anongit.kde.org/"]
insteadOf = kde:
[url "ssh://git@git.kde.org/"]
pushInsteadOf = kde:
EOF
Now activate this file
. /root/.bashrc

= Aquire and Build KDE as root =
If something fails you may need to make clean.

== automoc ==
automoc is needed for akonadi.
cd
git clone kde:automoc
cd automoc
cmakekde

== akonadi ==
Akonadi keeps personal information management data in a mysql database. It is needed for KDEPIMLIBS.
cd
git clone kde:akonadi
cd akonadi
cmakekde

== libattica ==
cd
git clone kde:attica
cd attica
cmakekde

== shared desktop ontologies ==
shared desktop ontologies is needed by kdepimlibs in order to build Nepomuk (which is a part of kdelibs)
cd
wget http://downloads.sourceforge.net/project/oscaf/shared-desktop-ontologies/0.9/shared-desktop-ontologies-0.9.0.tar.bz2
bunzip2 shared-desktop-ontologies-0.9.0.tar.bz2
tar xvf shared-desktop-ontologies-0.9.0.tar
cd shared-desktop-ontologies-0.9.0/
cmake . && make && make install

== phonon ==
Phonon is needed for kdebase-runtime
cd
git clone git://anongit.kde.org/phonon
cd phonon
cmakekde

== kdelibs ==
KDELIBS requires an out-of-source build, that is why it is more complicated to build:
cd
git clone kde:kdelibs
mkdir kdelibs-build
cd kdelibs-build
cmakekdelibs
Verify it has been correctly installed - the following must be possible:
kde4-config --prefix
/usr/local

== kdepimlibs ==
kdepimlibs is needed for kde-runtime.
cd
git clone kde:kdepimlibs
cd kdepimlibs
cmakekde

== kactivities ==
kactivities is needed for kde-workspace.
cd
git clone kde:kactivities
cd kactivities
cmakekde

== kdebase ==
cd
git clone kde:kde-baseapps
git clone kde:konsole
git clone kde:kde-workspace
git clone kde:kde-runtime
cd kde-baseapps
cmakekde
cd
cd konsole
cmakekde
cd
cd kde-workspace
cmakekde
cd
cd kde-runtime
cmakekde

User:Tstaerk

2012-11-03T08:05:07Z

Tstaerk:

= My sites =
* http://www.staerk.de/thorsten
* http://www.linuxintro.org

= My bookmarks =
* [[Talk:Development/Tutorials/D-Bus/Introduction]]
* http://cia.vc/stats/author/tstaerk

= open a new repo =
http://sysadmin.kde.org/svnaccount/repo-request.php

= legacy svn =
I need to use
svn co svn+ssh://tstaerk@svn.kde.org/home/kde/trunk/

= What I have done =
* [[Getting Started/Build/KDE4]]
* http://wiki.kde.org/tiki-index.php?page=ProgrammingTutorial%2Fdbus

= KnowHow =
make a non-debug-release => cmake -DCMAKE_BUILD_TYPE=Release . && make && make install

On suse, install into /usr/lib64 instead of /usr/lib => libsuffix, see http://bugs.scribus.net/view.php?id=6010

= Wiki2mindMap =
Here's how I draw a mindmap of this wiki:
== Download all pages ==
wget http://developernew.kde.org/Special:Allpages
cat >spider<<EOF
#!/usr/bin/perl
require HTML::LinkExtor;
\$p = HTML::LinkExtor->new(\&parse, "");
sub parse {
my(\$tag, %links) = @_;
my (\$att, \$url) = @{[%links]};
print "\$url\n";
}
\$p->parse_file(\$ARGV[0]);
EOF
chmod 777 spider

./spider Special\:Allpages | \
grep "^/" | \
grep -v ":" | \
grep -v "?" | \
while read a
do wget "http://developernew.kde.org$a"
done

for file in $(ls --ignore="*:*")
do ./spider $file | \
grep "^/" | \
grep -v ":" | \
grep -v "?" | \
grep -v "Main_Page" | \
grep -v "Getting_Started$" | \
grep -v "/Contribute$" | \
grep -v "^/Projects$" | \
grep -v "^/Development$" | \
grep -v "^/Policies$" | \
grep -v "^/Projects$" | \
grep -v "^/Projects/NamingTheWiki$" | \
grep -v "^/Schedules$" | \
grep -v "^/favicon.ico$" | \
grep -v "/opensearch_desc.php$" | \
grep -v "^/$" | \
grep -v ".png$" | \
grep -v "^/Development/Tutorials$" | \
sed "s;^/.*/;;" | \
while read file2
do echo "\"$file\" -> \"$file2\""
done
done >datei

echo "# to create a ps file use 'dot -Tps -o graph.ps graph.dot' (dot it part of the graphviz package)" > graph.dot
echo "digraph \"Wikimap\" { " >> graph.dot
cat datei >>graph.dot
echo "}" >> graph.dot

dot -Tps -o graph.ps graph.dot

= Eclipse as IDE =
* http://javathreads.de/2008/07/subversion-unter-eclipse-ganymede-konfigurieren/
* http://nienhueser.de/blog/?p=19

Development/Tutorials/Using Qt Creator

2012-06-10T15:14:33Z

Tstaerk: /* have QtCreator do the git checkout */

<languages />
<translate>

__TOC__


QtCreator is an IDE from Nokia for Qt. It contains QtDesigner for UI design. This article describes:
* why to use Qt Creator
* how to create a new application
* how to load an existing application

== Why use Qt Creator == 


{|align="right"
|[[image:Snapshot-qtcreator.png|right|thumb|200px|KDE4's ktimetracker loaded as QtCreator project]]
|}
To create your C++ applications you can use any text editor. But life will be much easier if you gain QtCreator's features. That means
* you can get your source code saved, built and run with one click
* you get code-completion
* you can find all places in your source code where you call a function (e.g. "where do I call refresh()")
* you can go back to a more recent cursor position with your editor, even if this is in another file
* you can checkout and commit to Subversion or Git repositories without leaving your workflow

== Creating a new program == 


Here is a short example of how you can create a "hello world" application. For more information read the [http://qt.nokia.com/doc/designer-manual.html user documentation].


;Step 0:
Call QtCreator
<syntaxhighlight lang="bash">
qtcreator
</syntaxhighlight>
Then select New File or Project -> Qt C++ Project -> Qt Gui Application -> name = helloworld -> Next -> Next -> Finish


;Step 1:
Select Edit -> Forms -> mainwindow.ui. Add the widgets you want by drag-and-drop:


[[File:Designer-step1.png|200px]]


;Step 2:
Select the mainwindow. This is the one un-intuitive step. To lay out the objects in the mainwindow, you do not select the objects in the mainwindow, but the mainwindow itself.


[[File:Designer-step2.png|200px]]


;Step 3:
Select Form -> Lay Out in a <u>G</u>rid


[[File:Designer-step3.png|200px]]


;Result:
You get a decent look, and if you resize the window, the widgets resize as well.


[[File:Designer-result.png|200px]]

=== Using KDE libraries === 


To use KDE classes like KMessageBox, you need to tell QtCreator to use the KDE libraries when building. Go to your home directory, change into ''yourproject'' and modify ''yourproject.pro''. Add the line
<syntaxhighlight lang="make">
LIBS += -lkdeui
</syntaxhighlight>
Then you can start using KDE classes in your code.

=== Adding a toolbar === 


To add a toolbar, right-click on the UI and choose "Add Toolbar". Then you can set icons and text in your mainwindow's constructor with code like this:
<syntaxhighlight lang="cpp-qt">
ui->toolBar->addAction(QIcon("/usr/share/icons/oxygen/22x22/apps/ktip.png"),"hello world");
</syntaxhighlight>
[[Development/Tutorials/Using_Qt_Designer|More Info...]]

== Load an existing project == 


This describes how to use QtCreator to integrate existing KDE 4 applications. It has been tested with QtCreator 1.2.80 and SUSE Linux 11.1 but should work same or similar with every combination. As an example KDE application we use [http://userbase.kde.org/ktimetracker ktimetracker] from the kdepim module, other applications should work likewise.


You can either work with code on your disk or have QtCreator do the Subversion checkout.

=== use code from your disk === 


* import the CMakeLists.txt file (File -> Open -> kdepim/CMakeLists.txt)
* as build directory choose kdepim
* you will automatically come to a screen where you can run CMake
* continue with the step "Run cmake"

=== have QtCreator do the subversion checkout === 


* choose File -> New File or Project -> Version Control -> Subversion Checkout.
* enter a Subversion URL like svn://anonsvn.kde.org/home/kde/trunk/KDE/kdepim
* enter a checkout directory, i.e. the local directory where the code will be checked-out to
* type finish, see how the checkout starts
* you will automatically come to a screen where you can run CMake
* continue with the step "Run cmake"

=== have QtCreator do the git checkout === 


* choose File -> New File or Project -> Project from Version Control -> Git Repository Clone.
* enter a Git URL like git@git.kde.org:/kdepim
* accept kdepim as checkout directory
* type finish, see how the checkout starts
* you will automatically come to a screen where you can run CMake
* continue with the step "Run cmake"

=== Run cmake === 


* enter arguments for CMake like
<syntaxhighlight lang="bash">
/root/kdepim -DCMAKE_INSTALL_PREFIX=/usr/local -DLIB_SUFFIX=64 -DCMAKE_BUILD_TYPE=debugfull
</syntaxhighlight>
<tt>DLIB_SUFFIX=64</tt> means that you want to install your libraries into directories named <tt>lib64</tt>, not <tt>lib</tt>. ''/root/kdepim'' is where your source code is.
* click "Run cmake"
* note: a .cbp file is created containing many information about the build
* click "Finish"

=== Build it === 


* configure QtCreator to build only ktimetracker:
Projects -> Active run configuration=ktimetracker -> build settings -> build steps -> make -> show details -> activate ktimetracker.
* configure QtCreator to use 8 logical processors:
Projects -> Active run configuration=ktimetracker -> build settings -> build steps -> make -> show details -> addtional Arguments = -j8
* choose Build -> Build All

== See also == 


* [[Development/Tutorials/Using Qt Designer]]
* [[Getting_Started/Using_an_IDE_with_KDE4#QtCreator]]
</translate>
[[Category:KDE4]]

Getting Started/Build/KDE4/on virtual machines

2012-06-10T14:52:25Z

Tstaerk: kdepimlibs is again needed :(

{{Infobox tutorial|time=3 hours|type=HowTo|distribution=SUSE Linux 12.1|happyreaders=2|unhappyreaders=0}}

This describes how to use a virtual machine for building the latest KDE from sources.

= Virtual Machine Setup =
Create a virtual machine, e.g. using [http://www.linuxintro.org/wiki/VMWare VMware Player]. Regarding harddisk: KDE 4 fits into 10 GB, however [[User:Tstaerk|I]] recommend 40GB, one partition. Regarding RAM: You will need at least 1GB ram for the virtual machine, of course more is better.

;You will need to set your SUSE CD as your virtual machine's cdrom.

== setup for SSH ==
To be able to log in to your VM using ssh, stop and disable the firewall:
rcSuSEfirewall2 stop
chkconfig SuSEfirewall2_setup off
chkconfig SuSEfirewall2_init off
/etc/init.d/sshd start
chkconfig sshd on
Inside the VM, install some needed packages:
yast -i libqt4-devel libsoprano-devel pcre-devel libxslt-devel libxml2-devel docbook-xsl-stylesheets git cmake \
libdbusmenu-qt-devel giflib-devel strigi-devel libQtWebKit-devel libqimageblitz-devel libical-devel libgpgme-devel

;Now it is time to do a snapshot or clone from your VM.
You will be able to return to this machine state whenever you want.

== a few more steps ==
Open a console as root
su -

== on an x64 distribution ==
If and only if you have a /lib64 path, you are on an x64 distribution.
Make sure you have the needed environment variables and alias set by having a file /root/.bashrc.
cd
cat >.bashrc<<EOF
export KDEDIR=/usr/local
alias cmakekde="cmake . -DCMAKE_INSTALL_PREFIX=\$KDEDIR -DLIB_SUFFIX=64 -D[[Development/CMake/Addons_for_KDE#Buildtypes|CMAKE_BUILD_TYPE]]=debugfull && make -j8 && make install"
alias cmakekdelibs="cmake ../kdelibs -DCMAKE_INSTALL_PREFIX=\$KDEDIR -DLIB_SUFFIX=64 -DCMAKE_BUILD_TYPE=debugfull && make -j8 && make install"
alias makeqt="./configure -dbus -openssl -plugin-sql-mysql -libdir /usr/lib64 -prefix /usr && make -j8 && make install"
export QTDIR=/usr
EOF
cat >.gitconfig<<EOF
[url "git://anongit.kde.org/"]
insteadOf = kde:
[url "ssh://git@git.kde.org/"]
pushInsteadOf = kde:
EOF
Now activate this file
. /root/.bashrc

== on another distribution (incl 32bit)==
Make sure you have the needed environment variables and alias set by having a file /root/.bashrc.
cd
cat >.bashrc<<EOF
export KDEDIR=/usr/local
alias cmakekde="cmake . -DCMAKE_INSTALL_PREFIX=\$KDEDIR -DCMAKE_BUILD_TYPE=debugfull && make -j8 && make install"
alias cmakekdelibs="cmake ../kdelibs -DCMAKE_INSTALL_PREFIX=\$KDEDIR -DCMAKE_BUILD_TYPE=debugfull && make -j8 && make install"
alias makeqt="./configure -dbus -openssl -plugin-sql-mysql -prefix /usr && make -j8 && make install"
export QTDIR=/usr
EOF
cat >.gitconfig<<EOF
[url "git://anongit.kde.org/"]
insteadOf = kde:
[url "ssh://git@git.kde.org/"]
pushInsteadOf = kde:
EOF
Now activate this file
. /root/.bashrc

= Aquire and Build KDE as root =
If something fails you may need to make clean.

== automoc ==
automoc is needed for akonadi.
cd
git clone kde:automoc
cd automoc
cmakekde

== akonadi ==
Akonadi keeps personal information management data in a mysql database. It is needed for KDEPIMLIBS.
cd
git clone kde:akonadi
cd akonadi
cmakekde

== libattica ==
cd
git clone kde:attica
cd attica
cmakekde

== shared desktop ontologies ==
shared desktop ontologies is needed by kdepimlibs in order to build Nepomuk (which is a part of kdelibs)
cd
wget http://downloads.sourceforge.net/project/oscaf/shared-desktop-ontologies/0.9/shared-desktop-ontologies-0.9.0.tar.bz2
bunzip2 shared-desktop-ontologies-0.9.0.tar.bz2
tar xvf shared-desktop-ontologies-0.9.0.tar
cd shared-desktop-ontologies-0.9.0/
cmake . && make && make install

== phonon ==
Phonon is needed for kdebase-runtime
cd
git clone git://anongit.kde.org/phonon
cd phonon
cmakekde

== kdelibs ==
KDELIBS requires an out-of-source build, that is why it is more complicated to build:
cd
git clone kde:kdelibs
mkdir kdelibs-build
cd kdelibs-build
cmakekdelibs
Verify it has been correctly installed - the following must be possible:
kde4-config --prefix
/usr/local

== kdepimlibs ==
kdepimlibs is needed for kde-runtime.
cd
git clone kde:kdepimlibs
cd kdepimlibs
cmakekde

== kactivities ==
kactivities is needed for kde-workspace.
cd
git clone kde:kactivities
cd kactivities
cmakekde

== kdebase ==
cd
git clone kde:kde-baseapps
git clone kde:konsole
git clone kde:kde-workspace
git clone kde:kde-runtime
cd kde-baseapps
cmakekde
cd
cd konsole
cmakekde
cd
cd kde-workspace
cmakekde
cd
cd kde-runtime
cmakekde

Getting Started/Build/KDE4/on virtual machines

2012-06-10T14:36:02Z

Tstaerk: /* setup for SSH */

{{Infobox tutorial|time=3 hours|type=HowTo|distribution=SUSE Linux 12.1|happyreaders=2|unhappyreaders=0}}

This describes how to use a virtual machine for building the latest KDE from sources.

= Virtual Machine Setup =
Create a virtual machine, e.g. using [http://www.linuxintro.org/wiki/VMWare VMware Player]. Regarding harddisk: KDE 4 fits into 10 GB, however [[User:Tstaerk|I]] recommend 40GB, one partition. Regarding RAM: You will need at least 1GB ram for the virtual machine, of course more is better.

;You will need to set your SUSE CD as your virtual machine's cdrom.

== setup for SSH ==
To be able to log in to your VM using ssh, stop and disable the firewall:
rcSuSEfirewall2 stop
chkconfig SuSEfirewall2_setup off
chkconfig SuSEfirewall2_init off
/etc/init.d/sshd start
chkconfig sshd on
Inside the VM, install some needed packages:
yast -i libqt4-devel libsoprano-devel pcre-devel libxslt-devel libxml2-devel docbook-xsl-stylesheets git cmake \
libdbusmenu-qt-devel giflib-devel strigi-devel libQtWebKit-devel libqimageblitz-devel

;Now it is time to do a snapshot or clone from your VM.
You will be able to return to this machine state whenever you want.

== a few more steps ==
Open a console as root
su -

== on an x64 distribution ==
If and only if you have a /lib64 path, you are on an x64 distribution.
Make sure you have the needed environment variables and alias set by having a file /root/.bashrc.
cd
cat >.bashrc<<EOF
export KDEDIR=/usr/local
alias cmakekde="cmake . -DCMAKE_INSTALL_PREFIX=\$KDEDIR -DLIB_SUFFIX=64 -D[[Development/CMake/Addons_for_KDE#Buildtypes|CMAKE_BUILD_TYPE]]=debugfull && make -j8 && make install"
alias cmakekdelibs="cmake ../kdelibs -DCMAKE_INSTALL_PREFIX=\$KDEDIR -DLIB_SUFFIX=64 -DCMAKE_BUILD_TYPE=debugfull && make -j8 && make install"
alias makeqt="./configure -dbus -openssl -plugin-sql-mysql -libdir /usr/lib64 -prefix /usr && make -j8 && make install"
export QTDIR=/usr
EOF
cat >.gitconfig<<EOF
[url "git://anongit.kde.org/"]
insteadOf = kde:
[url "ssh://git@git.kde.org/"]
pushInsteadOf = kde:
EOF
Now activate this file
. /root/.bashrc

== on another distribution (incl 32bit)==
Make sure you have the needed environment variables and alias set by having a file /root/.bashrc.
cd
cat >.bashrc<<EOF
export KDEDIR=/usr/local
alias cmakekde="cmake . -DCMAKE_INSTALL_PREFIX=\$KDEDIR -DCMAKE_BUILD_TYPE=debugfull && make -j8 && make install"
alias cmakekdelibs="cmake ../kdelibs -DCMAKE_INSTALL_PREFIX=\$KDEDIR -DCMAKE_BUILD_TYPE=debugfull && make -j8 && make install"
alias makeqt="./configure -dbus -openssl -plugin-sql-mysql -prefix /usr && make -j8 && make install"
export QTDIR=/usr
EOF
cat >.gitconfig<<EOF
[url "git://anongit.kde.org/"]
insteadOf = kde:
[url "ssh://git@git.kde.org/"]
pushInsteadOf = kde:
EOF
Now activate this file
. /root/.bashrc

= Aquire and Build KDE as root =
If something fails you may need to make clean.

== automoc ==
automoc is needed for akonadi.
cd
git clone kde:automoc
cd automoc
cmakekde

== akonadi ==
Akonadi keeps personal information management data in a mysql database. It is needed for KDEPIMLIBS.
cd
git clone kde:akonadi
cd akonadi
cmakekde

== libattica ==
cd
git clone kde:attica
cd attica
cmakekde

== shared desktop ontologies ==
shared desktop ontologies is needed by kdepimlibs in order to build Nepomuk (which is a part of kdelibs)
cd
wget http://downloads.sourceforge.net/project/oscaf/shared-desktop-ontologies/0.9/shared-desktop-ontologies-0.9.0.tar.bz2
bunzip2 shared-desktop-ontologies-0.9.0.tar.bz2
tar xvf shared-desktop-ontologies-0.9.0.tar
cd shared-desktop-ontologies-0.9.0/
cmake . && make && make install

== phonon ==
Phonon is needed for kdebase-runtime
cd
git clone git://anongit.kde.org/phonon
cd phonon
cmakekde

== kdelibs ==
KDELIBS requires an out-of-source build, that is why it is more complicated to build:
cd
git clone kde:kdelibs
mkdir kdelibs-build
cd kdelibs-build
cmakekdelibs
Verify it has been correctly installed - the following must be possible:
kde4-config --prefix
/usr/local

== kactivities ==
kactivities is needed for kde-workspace.
cd
git clone kde:kactivities
cd kactivities
cmakekde

== kdebase ==
cd
git clone kde:kde-baseapps
git clone kde:konsole
git clone kde:kde-workspace
git clone kde:kde-runtime
cd kde-baseapps
cmakekde
cd
cd konsole
cmakekde
cd
cd kde-workspace
cmakekde
cd
cd kde-runtime
cmakekde

Thread:User talk:Icwiener/thanks

2012-06-10T13:57:36Z

Tstaerk: New thread: thanks

thanks a lot for [[http://techbase.kde.org/index.php?title=Development%2FTutorials%2FUsing_Qt_Creator&action=historysubmit&diff=66374&oldid=66177 this]] --[[User:Tstaerk|Tstaerk]] 14:57, 10 June 2012 (BST)

User talk:Icwiener

2012-06-10T13:57:36Z

Tstaerk: Talk page autocreated when first thread was posted

Getting Started/Build/KDE4/on virtual machines

2012-06-10T13:28:10Z

Tstaerk: /* shared desktop ontologies */

{{Infobox tutorial|time=3 hours|type=HowTo|distribution=SUSE Linux 12.1|happyreaders=2|unhappyreaders=0}}

This describes how to use a virtual machine for building the latest KDE from sources.

= Virtual Machine Setup =
Create a virtual machine, e.g. using [http://www.linuxintro.org/wiki/VMWare VMware Player]. Regarding harddisk: KDE 4 fits into 10 GB, however [[User:Tstaerk|I]] recommend 40GB, one partition. Regarding RAM: You will need at least 1GB ram for the virtual machine, of course more is better.

;You will need to set your SUSE CD as your virtual machine's cdrom.

== setup for SSH ==
To be able to log in to your VM using ssh, stop and disable the firewall:
rcSuSEfirewall2 stop
chkconfig SuSEfirewall2_setup off
chkconfig SuSEfirewall2_init off
/etc/init.d/sshd start
chkconfig sshd on
Inside the VM, install some needed packages:
yast -i libqt4-devel libsoprano-devel pcre-devel libxslt-devel libxml2-devel docbook-xsl-stylesheets git cmake \
libdbusmenu-qt-devel giflib-devel strigi-devel libQtWebKit-devel

;Now it is time to do a snapshot or clone from your VM.
You will be able to return to this machine state whenever you want.

== a few more steps ==
Open a console as root
su -

== on an x64 distribution ==
If and only if you have a /lib64 path, you are on an x64 distribution.
Make sure you have the needed environment variables and alias set by having a file /root/.bashrc.
cd
cat >.bashrc<<EOF
export KDEDIR=/usr/local
alias cmakekde="cmake . -DCMAKE_INSTALL_PREFIX=\$KDEDIR -DLIB_SUFFIX=64 -D[[Development/CMake/Addons_for_KDE#Buildtypes|CMAKE_BUILD_TYPE]]=debugfull && make -j8 && make install"
alias cmakekdelibs="cmake ../kdelibs -DCMAKE_INSTALL_PREFIX=\$KDEDIR -DLIB_SUFFIX=64 -DCMAKE_BUILD_TYPE=debugfull && make -j8 && make install"
alias makeqt="./configure -dbus -openssl -plugin-sql-mysql -libdir /usr/lib64 -prefix /usr && make -j8 && make install"
export QTDIR=/usr
EOF
cat >.gitconfig<<EOF
[url "git://anongit.kde.org/"]
insteadOf = kde:
[url "ssh://git@git.kde.org/"]
pushInsteadOf = kde:
EOF
Now activate this file
. /root/.bashrc

== on another distribution (incl 32bit)==
Make sure you have the needed environment variables and alias set by having a file /root/.bashrc.
cd
cat >.bashrc<<EOF
export KDEDIR=/usr/local
alias cmakekde="cmake . -DCMAKE_INSTALL_PREFIX=\$KDEDIR -DCMAKE_BUILD_TYPE=debugfull && make -j8 && make install"
alias cmakekdelibs="cmake ../kdelibs -DCMAKE_INSTALL_PREFIX=\$KDEDIR -DCMAKE_BUILD_TYPE=debugfull && make -j8 && make install"
alias makeqt="./configure -dbus -openssl -plugin-sql-mysql -prefix /usr && make -j8 && make install"
export QTDIR=/usr
EOF
cat >.gitconfig<<EOF
[url "git://anongit.kde.org/"]
insteadOf = kde:
[url "ssh://git@git.kde.org/"]
pushInsteadOf = kde:
EOF
Now activate this file
. /root/.bashrc

= Aquire and Build KDE as root =
If something fails you may need to make clean.

== automoc ==
automoc is needed for akonadi.
cd
git clone kde:automoc
cd automoc
cmakekde

== akonadi ==
Akonadi keeps personal information management data in a mysql database. It is needed for KDEPIMLIBS.
cd
git clone kde:akonadi
cd akonadi
cmakekde

== libattica ==
cd
git clone kde:attica
cd attica
cmakekde

== shared desktop ontologies ==
shared desktop ontologies is needed by kdepimlibs in order to build Nepomuk (which is a part of kdelibs)
cd
wget http://downloads.sourceforge.net/project/oscaf/shared-desktop-ontologies/0.9/shared-desktop-ontologies-0.9.0.tar.bz2
bunzip2 shared-desktop-ontologies-0.9.0.tar.bz2
tar xvf shared-desktop-ontologies-0.9.0.tar
cd shared-desktop-ontologies-0.9.0/
cmake . && make && make install

== phonon ==
Phonon is needed for kdebase-runtime
cd
git clone git://anongit.kde.org/phonon
cd phonon
cmakekde

== kdelibs ==
KDELIBS requires an out-of-source build, that is why it is more complicated to build:
cd
git clone kde:kdelibs
mkdir kdelibs-build
cd kdelibs-build
cmakekdelibs
Verify it has been correctly installed - the following must be possible:
kde4-config --prefix
/usr/local

== kactivities ==
kactivities is needed for kde-workspace.
cd
git clone kde:kactivities
cd kactivities
cmakekde

== kdebase ==
cd
git clone kde:kde-baseapps
git clone kde:konsole
git clone kde:kde-workspace
git clone kde:kde-runtime
cd kde-baseapps
cmakekde
cd
cd konsole
cmakekde
cd
cd kde-workspace
cmakekde
cd
cd kde-runtime
cmakekde

Getting Started/Build/KDE4/on virtual machines

2012-04-01T12:51:40Z

Tstaerk: /* shared desktop ontologies */

{{Infobox tutorial|time=3 hours|type=HowTo|distribution=SUSE Linux 12.1|happyreaders=2|unhappyreaders=0}}

This describes how to use a virtual machine for building the latest KDE from sources.

= Virtual Machine Setup =
Create a virtual machine, e.g. using [http://www.linuxintro.org/wiki/VMWare VMware Player]. Regarding harddisk: KDE 4 fits into 10 GB, however [[User:Tstaerk|I]] recommend 40GB, one partition. Regarding RAM: You will need at least 1GB ram for the virtual machine, of course more is better.

;You will need to set your SUSE CD as your virtual machine's cdrom.

== setup for SSH ==
To be able to log in to your VM using ssh, stop and disable the firewall:
rcSuSEfirewall2 stop
chkconfig SuSEfirewall2_setup off
chkconfig SuSEfirewall2_init off
/etc/init.d/sshd start
chkconfig sshd on
Inside the VM, install some needed packages:
yast -i libqt4-devel libsoprano-devel pcre-devel libxslt-devel libxml2-devel docbook-xsl-stylesheets git cmake \
libdbusmenu-qt-devel giflib-devel strigi-devel libQtWebKit-devel

;Now it is time to do a snapshot or clone from your VM.
You will be able to return to this machine state whenever you want.

== a few more steps ==
Open a console as root
su -

== on an x64 distribution ==
If and only if you have a /lib64 path, you are on an x64 distribution.
Make sure you have the needed environment variables and alias set by having a file /root/.bashrc.
cd
cat >.bashrc<<EOF
export KDEDIR=/usr/local
alias cmakekde="cmake . -DCMAKE_INSTALL_PREFIX=\$KDEDIR -DLIB_SUFFIX=64 -D[[Development/CMake/Addons_for_KDE#Buildtypes|CMAKE_BUILD_TYPE]]=debugfull && make -j8 && make install"
alias cmakekdelibs="cmake ../kdelibs -DCMAKE_INSTALL_PREFIX=\$KDEDIR -DLIB_SUFFIX=64 -DCMAKE_BUILD_TYPE=debugfull && make -j8 && make install"
alias makeqt="./configure -dbus -openssl -plugin-sql-mysql -libdir /usr/lib64 -prefix /usr && make -j8 && make install"
export QTDIR=/usr
EOF
cat >.gitconfig<<EOF
[url "git://anongit.kde.org/"]
insteadOf = kde:
[url "ssh://git@git.kde.org/"]
pushInsteadOf = kde:
EOF
Now activate this file
. /root/.bashrc

== on another distribution (incl 32bit)==
Make sure you have the needed environment variables and alias set by having a file /root/.bashrc.
cd
cat >.bashrc<<EOF
export KDEDIR=/usr/local
alias cmakekde="cmake . -DCMAKE_INSTALL_PREFIX=\$KDEDIR -DCMAKE_BUILD_TYPE=debugfull && make -j8 && make install"
alias cmakekdelibs="cmake ../kdelibs -DCMAKE_INSTALL_PREFIX=\$KDEDIR -DCMAKE_BUILD_TYPE=debugfull && make -j8 && make install"
alias makeqt="./configure -dbus -openssl -plugin-sql-mysql -prefix /usr && make -j8 && make install"
export QTDIR=/usr
EOF
cat >.gitconfig<<EOF
[url "git://anongit.kde.org/"]
insteadOf = kde:
[url "ssh://git@git.kde.org/"]
pushInsteadOf = kde:
EOF
Now activate this file
. /root/.bashrc

= Aquire and Build KDE as root =
If something fails you may need to make clean.

== automoc ==
automoc is needed for akonadi.
cd
git clone kde:automoc
cd automoc
cmakekde

== akonadi ==
Akonadi keeps personal information management data in a mysql database. It is needed for KDEPIMLIBS.
cd
git clone kde:akonadi
cd akonadi
cmakekde

== libattica ==
cd
git clone kde:attica
cd attica
cmakekde

== shared desktop ontologies ==
shared desktop ontologies is needed by kdepimlibs in order to build Nepomuk (which is a part of kdelibs)
cd
wget http://downloads.sourceforge.net/project/oscaf/shared-desktop-ontologies/0.8/shared-desktop-ontologies-0.9.0.tar.bz2
bunzip2 shared-desktop-ontologies-0.9.0.tar.bz2
tar xvf shared-desktop-ontologies-0.9.0.tar
cd shared-desktop-ontologies-0.9.0/
cmake . && make && make install

== phonon ==
Phonon is needed for kdebase-runtime
cd
git clone git://anongit.kde.org/phonon
cd phonon
cmakekde

== kdelibs ==
KDELIBS requires an out-of-source build, that is why it is more complicated to build:
cd
git clone kde:kdelibs
mkdir kdelibs-build
cd kdelibs-build
cmakekdelibs
Verify it has been correctly installed - the following must be possible:
kde4-config --prefix
/usr/local

== kactivities ==
kactivities is needed for kde-workspace.
cd
git clone kde:kactivities
cd kactivities
cmakekde

== kdebase ==
cd
git clone kde:kde-baseapps
git clone kde:konsole
git clone kde:kde-workspace
git clone kde:kde-runtime
cd kde-baseapps
cmakekde
cd
cd konsole
cmakekde
cd
cd kde-workspace
cmakekde
cd
cd kde-runtime
cmakekde

Getting Started/Build/KDE4/on virtual machines

2012-04-01T12:26:15Z

Tstaerk: no longer needed with SUSE 12.1.

{{Infobox tutorial|time=3 hours|type=HowTo|distribution=SUSE Linux 12.1|happyreaders=2|unhappyreaders=0}}

This describes how to use a virtual machine for building the latest KDE from sources.

= Virtual Machine Setup =
Create a virtual machine, e.g. using [http://www.linuxintro.org/wiki/VMWare VMware Player]. Regarding harddisk: KDE 4 fits into 10 GB, however [[User:Tstaerk|I]] recommend 40GB, one partition. Regarding RAM: You will need at least 1GB ram for the virtual machine, of course more is better.

;You will need to set your SUSE CD as your virtual machine's cdrom.

== setup for SSH ==
To be able to log in to your VM using ssh, stop and disable the firewall:
rcSuSEfirewall2 stop
chkconfig SuSEfirewall2_setup off
chkconfig SuSEfirewall2_init off
/etc/init.d/sshd start
chkconfig sshd on
Inside the VM, install some needed packages:
yast -i libqt4-devel libsoprano-devel pcre-devel libxslt-devel libxml2-devel docbook-xsl-stylesheets git cmake \
libdbusmenu-qt-devel giflib-devel strigi-devel libQtWebKit-devel

;Now it is time to do a snapshot or clone from your VM.
You will be able to return to this machine state whenever you want.

== a few more steps ==
Open a console as root
su -

== on an x64 distribution ==
If and only if you have a /lib64 path, you are on an x64 distribution.
Make sure you have the needed environment variables and alias set by having a file /root/.bashrc.
cd
cat >.bashrc<<EOF
export KDEDIR=/usr/local
alias cmakekde="cmake . -DCMAKE_INSTALL_PREFIX=\$KDEDIR -DLIB_SUFFIX=64 -D[[Development/CMake/Addons_for_KDE#Buildtypes|CMAKE_BUILD_TYPE]]=debugfull && make -j8 && make install"
alias cmakekdelibs="cmake ../kdelibs -DCMAKE_INSTALL_PREFIX=\$KDEDIR -DLIB_SUFFIX=64 -DCMAKE_BUILD_TYPE=debugfull && make -j8 && make install"
alias makeqt="./configure -dbus -openssl -plugin-sql-mysql -libdir /usr/lib64 -prefix /usr && make -j8 && make install"
export QTDIR=/usr
EOF
cat >.gitconfig<<EOF
[url "git://anongit.kde.org/"]
insteadOf = kde:
[url "ssh://git@git.kde.org/"]
pushInsteadOf = kde:
EOF
Now activate this file
. /root/.bashrc

== on another distribution (incl 32bit)==
Make sure you have the needed environment variables and alias set by having a file /root/.bashrc.
cd
cat >.bashrc<<EOF
export KDEDIR=/usr/local
alias cmakekde="cmake . -DCMAKE_INSTALL_PREFIX=\$KDEDIR -DCMAKE_BUILD_TYPE=debugfull && make -j8 && make install"
alias cmakekdelibs="cmake ../kdelibs -DCMAKE_INSTALL_PREFIX=\$KDEDIR -DCMAKE_BUILD_TYPE=debugfull && make -j8 && make install"
alias makeqt="./configure -dbus -openssl -plugin-sql-mysql -prefix /usr && make -j8 && make install"
export QTDIR=/usr
EOF
cat >.gitconfig<<EOF
[url "git://anongit.kde.org/"]
insteadOf = kde:
[url "ssh://git@git.kde.org/"]
pushInsteadOf = kde:
EOF
Now activate this file
. /root/.bashrc

= Aquire and Build KDE as root =
If something fails you may need to make clean.

== automoc ==
automoc is needed for akonadi.
cd
git clone kde:automoc
cd automoc
cmakekde

== akonadi ==
Akonadi keeps personal information management data in a mysql database. It is needed for KDEPIMLIBS.
cd
git clone kde:akonadi
cd akonadi
cmakekde

== libattica ==
cd
git clone kde:attica
cd attica
cmakekde

== shared desktop ontologies ==
shared desktop ontologies is needed by kdepimlibs in order to build Nepomuk (which is a part of kdelibs)
cd
wget http://downloads.sourceforge.net/project/oscaf/shared-desktop-ontologies/0.8/shared-desktop-ontologies-0.8.0.tar.bz2
bunzip2 shared-desktop-ontologies-0.8.0.tar.bz2
tar xvf shared-desktop-ontologies-0.8.0.tar
cd shared-desktop-ontologies-0.8.0/
cmake . && make && make install

== phonon ==
Phonon is needed for kdebase-runtime
cd
git clone git://anongit.kde.org/phonon
cd phonon
cmakekde

== kdelibs ==
KDELIBS requires an out-of-source build, that is why it is more complicated to build:
cd
git clone kde:kdelibs
mkdir kdelibs-build
cd kdelibs-build
cmakekdelibs
Verify it has been correctly installed - the following must be possible:
kde4-config --prefix
/usr/local

== kactivities ==
kactivities is needed for kde-workspace.
cd
git clone kde:kactivities
cd kactivities
cmakekde

== kdebase ==
cd
git clone kde:kde-baseapps
git clone kde:konsole
git clone kde:kde-workspace
git clone kde:kde-runtime
cd kde-baseapps
cmakekde
cd
cd konsole
cmakekde
cd
cd kde-workspace
cmakekde
cd
cd kde-runtime
cmakekde

Getting Started/Build/KDE4/on virtual machines

2012-02-12T13:44:48Z

Tstaerk: /* setup for SSH */

{{Infobox tutorial|time=3 hours|type=HowTo|distribution=SUSE Linux 12.1|happyreaders=2|unhappyreaders=0}}

This describes how to use a virtual machine for building the latest KDE from sources.

= Virtual Machine Setup =
Create a virtual machine, e.g. using [http://www.linuxintro.org/wiki/VMWare VMware Player]. Regarding harddisk: KDE 4 fits into 10 GB, however [[User:Tstaerk|I]] recommend 40GB, one partition. Regarding RAM: You will need at least 1GB ram for the virtual machine, of course more is better.

;You will need to set your SUSE CD as your virtual machine's cdrom.

== setup for SSH ==
To be able to log in to your VM using ssh, stop and disable the firewall:
rcSuSEfirewall2 stop
chkconfig SuSEfirewall2_setup off
chkconfig SuSEfirewall2_init off
/etc/init.d/sshd start
chkconfig sshd on
Inside the VM, install some needed packages:
yast -i libqt4-devel libsoprano-devel pcre-devel libxslt-devel libxml2-devel docbook-xsl-stylesheets git cmake \
libdbusmenu-qt-devel giflib-devel strigi-devel libQtWebKit-devel

;Now it is time to do a snapshot or clone from your VM.
You will be able to return to this machine state whenever you want.

== a few more steps ==
Open a console as root
su -

== on an x64 distribution ==
If and only if you have a /lib64 path, you are on an x64 distribution.
Make sure you have the needed environment variables and alias set by having a file /root/.bashrc.
cd
cat >.bashrc<<EOF
export KDEDIR=/usr/local
alias cmakekde="cmake . -DCMAKE_INSTALL_PREFIX=\$KDEDIR -DLIB_SUFFIX=64 -D[[Development/CMake/Addons_for_KDE#Buildtypes|CMAKE_BUILD_TYPE]]=debugfull && make -j8 && make install"
alias cmakekdelibs="cmake ../kdelibs -DCMAKE_INSTALL_PREFIX=\$KDEDIR -DLIB_SUFFIX=64 -DCMAKE_BUILD_TYPE=debugfull && make -j8 && make install"
alias makeqt="./configure -dbus -openssl -plugin-sql-mysql -libdir /usr/lib64 -prefix /usr && make -j8 && make install"
export QTDIR=/usr
EOF
cat >.gitconfig<<EOF
[url "git://anongit.kde.org/"]
insteadOf = kde:
[url "ssh://git@git.kde.org/"]
pushInsteadOf = kde:
EOF
Now activate this file
. /root/.bashrc

== on another distribution (incl 32bit)==
Make sure you have the needed environment variables and alias set by having a file /root/.bashrc.
cd
cat >.bashrc<<EOF
export KDEDIR=/usr/local
alias cmakekde="cmake . -DCMAKE_INSTALL_PREFIX=\$KDEDIR -DCMAKE_BUILD_TYPE=debugfull && make -j8 && make install"
alias cmakekdelibs="cmake ../kdelibs -DCMAKE_INSTALL_PREFIX=\$KDEDIR -DCMAKE_BUILD_TYPE=debugfull && make -j8 && make install"
alias makeqt="./configure -dbus -openssl -plugin-sql-mysql -prefix /usr && make -j8 && make install"
export QTDIR=/usr
EOF
cat >.gitconfig<<EOF
[url "git://anongit.kde.org/"]
insteadOf = kde:
[url "ssh://git@git.kde.org/"]
pushInsteadOf = kde:
EOF
Now activate this file
. /root/.bashrc

= Aquire and Build KDE as root =
If something fails you may need to make clean.

== automoc ==
automoc is needed for akonadi.
cd
git clone kde:automoc
cd automoc
cmakekde

== akonadi ==
Akonadi keeps personal information management data in a mysql database. It is needed for KDEPIMLIBS.
cd
git clone kde:akonadi
cd akonadi
cmakekde

== libattica ==
cd
git clone kde:attica
cd attica
cmakekde

== shared desktop ontologies ==
shared desktop ontologies is needed by kdepimlibs in order to build Nepomuk (which is a part of kdelibs)
cd
wget http://downloads.sourceforge.net/project/oscaf/shared-desktop-ontologies/0.8/shared-desktop-ontologies-0.8.0.tar.bz2
bunzip2 shared-desktop-ontologies-0.8.0.tar.bz2
tar xvf shared-desktop-ontologies-0.8.0.tar
cd shared-desktop-ontologies-0.8.0/
cmake . && make && make install

== phonon ==
Phonon is needed for kdebase-runtime
cd
git clone git://anongit.kde.org/phonon
cd phonon
cmakekde

== kdelibs ==
KDELIBS requires an out-of-source build, that is why it is more complicated to build:
cd
git clone kde:kdelibs
mkdir kdelibs-build
cd kdelibs-build
cmakekdelibs
Verify it has been correctly installed - the following must be possible:
kde4-config --prefix
/usr/local

== kactivities ==
kactivities is needed for kde-workspace.
cd
git clone kde:kactivities
cd kactivities
cmakekde

== kdebase ==
cd
git clone kde:kde-baseapps
git clone kde:konsole
git clone kde:kde-workspace
git clone kde:kde-runtime
cd kde-baseapps
cmakekde
cd
cd konsole
cmakekde
cd
cd kde-workspace
cmakekde
cd
cd kde-runtime
cmakekde

= Config =
First allow root login. You will need it as you do not have another login:
sed -i "s/AllowRootLogin.*/AllowRootLogin=true/g" /usr/local/share/config/kdm/kdmrc
Now stop your running display manager:
/etc/init.d/xdm stop
And start your self-compiled display manager:
kdm
To enable automated startup of your kdm, you need to change a SUSE-specific path in /etc/init.d/xdm:
KDM4_BIN=/usr/local/bin/kdm

Getting Started/Build/KDE4/on virtual machines

2012-02-12T13:29:55Z

Tstaerk: /* setup for SSH */

{{Infobox tutorial|time=3 hours|type=HowTo|distribution=SUSE Linux 12.1|happyreaders=2|unhappyreaders=0}}

This describes how to use a virtual machine for building the latest KDE from sources.

= Virtual Machine Setup =
Create a virtual machine, e.g. using [http://www.linuxintro.org/wiki/VMWare VMware Player]. Regarding harddisk: KDE 4 fits into 10 GB, however [[User:Tstaerk|I]] recommend 40GB, one partition. Regarding RAM: You will need at least 1GB ram for the virtual machine, of course more is better.

;You will need to set your SUSE CD as your virtual machine's cdrom.

== setup for SSH ==
To be able to log in to your VM using ssh, stop and disable the firewall:
rcSuSEfirewall2 stop
chkconfig SuSEfirewall2_setup off
chkconfig SuSEfirewall2_init off
/etc/init.d/sshd start
chkconfig sshd on
Inside the VM, install some needed packages:
yast -i libqt4-devel libsoprano-devel pcre-devel libxslt-devel libxml2-devel docbook-xsl-stylesheets git cmake \
libdbusmenu-qt-devel giflib-devel strigi-devel

;Now it is time to do a snapshot or clone from your VM.
You will be able to return to this machine state whenever you want.

== a few more steps ==
Open a console as root
su -

== on an x64 distribution ==
If and only if you have a /lib64 path, you are on an x64 distribution.
Make sure you have the needed environment variables and alias set by having a file /root/.bashrc.
cd
cat >.bashrc<<EOF
export KDEDIR=/usr/local
alias cmakekde="cmake . -DCMAKE_INSTALL_PREFIX=\$KDEDIR -DLIB_SUFFIX=64 -D[[Development/CMake/Addons_for_KDE#Buildtypes|CMAKE_BUILD_TYPE]]=debugfull && make -j8 && make install"
alias cmakekdelibs="cmake ../kdelibs -DCMAKE_INSTALL_PREFIX=\$KDEDIR -DLIB_SUFFIX=64 -DCMAKE_BUILD_TYPE=debugfull && make -j8 && make install"
alias makeqt="./configure -dbus -openssl -plugin-sql-mysql -libdir /usr/lib64 -prefix /usr && make -j8 && make install"
export QTDIR=/usr
EOF
cat >.gitconfig<<EOF
[url "git://anongit.kde.org/"]
insteadOf = kde:
[url "ssh://git@git.kde.org/"]
pushInsteadOf = kde:
EOF
Now activate this file
. /root/.bashrc

== on another distribution (incl 32bit)==
Make sure you have the needed environment variables and alias set by having a file /root/.bashrc.
cd
cat >.bashrc<<EOF
export KDEDIR=/usr/local
alias cmakekde="cmake . -DCMAKE_INSTALL_PREFIX=\$KDEDIR -DCMAKE_BUILD_TYPE=debugfull && make -j8 && make install"
alias cmakekdelibs="cmake ../kdelibs -DCMAKE_INSTALL_PREFIX=\$KDEDIR -DCMAKE_BUILD_TYPE=debugfull && make -j8 && make install"
alias makeqt="./configure -dbus -openssl -plugin-sql-mysql -prefix /usr && make -j8 && make install"
export QTDIR=/usr
EOF
cat >.gitconfig<<EOF
[url "git://anongit.kde.org/"]
insteadOf = kde:
[url "ssh://git@git.kde.org/"]
pushInsteadOf = kde:
EOF
Now activate this file
. /root/.bashrc

= Aquire and Build KDE as root =
If something fails you may need to make clean.

== automoc ==
automoc is needed for akonadi.
cd
git clone kde:automoc
cd automoc
cmakekde

== akonadi ==
Akonadi keeps personal information management data in a mysql database. It is needed for KDEPIMLIBS.
cd
git clone kde:akonadi
cd akonadi
cmakekde

== libattica ==
cd
git clone kde:attica
cd attica
cmakekde

== shared desktop ontologies ==
shared desktop ontologies is needed by kdepimlibs in order to build Nepomuk (which is a part of kdelibs)
cd
wget http://downloads.sourceforge.net/project/oscaf/shared-desktop-ontologies/0.8/shared-desktop-ontologies-0.8.0.tar.bz2
bunzip2 shared-desktop-ontologies-0.8.0.tar.bz2
tar xvf shared-desktop-ontologies-0.8.0.tar
cd shared-desktop-ontologies-0.8.0/
cmake . && make && make install

== phonon ==
Phonon is needed for kdebase-runtime
cd
git clone git://anongit.kde.org/phonon
cd phonon
cmakekde

== kdelibs ==
KDELIBS requires an out-of-source build, that is why it is more complicated to build:
cd
git clone kde:kdelibs
mkdir kdelibs-build
cd kdelibs-build
cmakekdelibs
Verify it has been correctly installed - the following must be possible:
kde4-config --prefix
/usr/local

== kactivities ==
kactivities is needed for kde-workspace.
cd
git clone kde:kactivities
cd kactivities
cmakekde

== kdebase ==
cd
git clone kde:kde-baseapps
git clone kde:konsole
git clone kde:kde-workspace
git clone kde:kde-runtime
cd kde-baseapps
cmakekde
cd
cd konsole
cmakekde
cd
cd kde-workspace
cmakekde
cd
cd kde-runtime
cmakekde

= Config =
First allow root login. You will need it as you do not have another login:
sed -i "s/AllowRootLogin.*/AllowRootLogin=true/g" /usr/local/share/config/kdm/kdmrc
Now stop your running display manager:
/etc/init.d/xdm stop
And start your self-compiled display manager:
kdm
To enable automated startup of your kdm, you need to change a SUSE-specific path in /etc/init.d/xdm:
KDM4_BIN=/usr/local/bin/kdm

Getting Started/Build/KDE4/on virtual machines

2012-02-12T13:28:51Z

Tstaerk: better use dbusmenu-qt-devel

{{Infobox tutorial|time=3 hours|type=HowTo|distribution=SUSE Linux 12.1|happyreaders=2|unhappyreaders=0}}

This describes how to use a virtual machine for building the latest KDE from sources.

= Virtual Machine Setup =
Create a virtual machine, e.g. using [http://www.linuxintro.org/wiki/VMWare VMware Player]. Regarding harddisk: KDE 4 fits into 10 GB, however [[User:Tstaerk|I]] recommend 40GB, one partition. Regarding RAM: You will need at least 1GB ram for the virtual machine, of course more is better.

;You will need to set your SUSE CD as your virtual machine's cdrom.

== setup for SSH ==
To be able to log in to your VM using ssh, stop and disable the firewall:
rcSuSEfirewall2 stop
chkconfig SuSEfirewall2_setup off
chkconfig SuSEfirewall2_init off
/etc/init.d/sshd start
chkconfig sshd on
Inside the VM, install some needed packages:
yast -i libqt4-devel libsoprano-devel pcre-devel libxslt-devel libxml2-devel docbook-xsl-stylesheets git cmake

;Now it is time to do a snapshot or clone from your VM.
You will be able to return to this machine state whenever you want.

== a few more steps ==
Open a console as root
su -

== on an x64 distribution ==
If and only if you have a /lib64 path, you are on an x64 distribution.
Make sure you have the needed environment variables and alias set by having a file /root/.bashrc.
cd
cat >.bashrc<<EOF
export KDEDIR=/usr/local
alias cmakekde="cmake . -DCMAKE_INSTALL_PREFIX=\$KDEDIR -DLIB_SUFFIX=64 -D[[Development/CMake/Addons_for_KDE#Buildtypes|CMAKE_BUILD_TYPE]]=debugfull && make -j8 && make install"
alias cmakekdelibs="cmake ../kdelibs -DCMAKE_INSTALL_PREFIX=\$KDEDIR -DLIB_SUFFIX=64 -DCMAKE_BUILD_TYPE=debugfull && make -j8 && make install"
alias makeqt="./configure -dbus -openssl -plugin-sql-mysql -libdir /usr/lib64 -prefix /usr && make -j8 && make install"
export QTDIR=/usr
EOF
cat >.gitconfig<<EOF
[url "git://anongit.kde.org/"]
insteadOf = kde:
[url "ssh://git@git.kde.org/"]
pushInsteadOf = kde:
EOF
Now activate this file
. /root/.bashrc

== on another distribution (incl 32bit)==
Make sure you have the needed environment variables and alias set by having a file /root/.bashrc.
cd
cat >.bashrc<<EOF
export KDEDIR=/usr/local
alias cmakekde="cmake . -DCMAKE_INSTALL_PREFIX=\$KDEDIR -DCMAKE_BUILD_TYPE=debugfull && make -j8 && make install"
alias cmakekdelibs="cmake ../kdelibs -DCMAKE_INSTALL_PREFIX=\$KDEDIR -DCMAKE_BUILD_TYPE=debugfull && make -j8 && make install"
alias makeqt="./configure -dbus -openssl -plugin-sql-mysql -prefix /usr && make -j8 && make install"
export QTDIR=/usr
EOF
cat >.gitconfig<<EOF
[url "git://anongit.kde.org/"]
insteadOf = kde:
[url "ssh://git@git.kde.org/"]
pushInsteadOf = kde:
EOF
Now activate this file
. /root/.bashrc

= Aquire and Build KDE as root =
If something fails you may need to make clean.

== automoc ==
automoc is needed for akonadi.
cd
git clone kde:automoc
cd automoc
cmakekde

== akonadi ==
Akonadi keeps personal information management data in a mysql database. It is needed for KDEPIMLIBS.
cd
git clone kde:akonadi
cd akonadi
cmakekde

== libattica ==
cd
git clone kde:attica
cd attica
cmakekde

== shared desktop ontologies ==
shared desktop ontologies is needed by kdepimlibs in order to build Nepomuk (which is a part of kdelibs)
cd
wget http://downloads.sourceforge.net/project/oscaf/shared-desktop-ontologies/0.8/shared-desktop-ontologies-0.8.0.tar.bz2
bunzip2 shared-desktop-ontologies-0.8.0.tar.bz2
tar xvf shared-desktop-ontologies-0.8.0.tar
cd shared-desktop-ontologies-0.8.0/
cmake . && make && make install

== phonon ==
Phonon is needed for kdebase-runtime
cd
git clone git://anongit.kde.org/phonon
cd phonon
cmakekde

== kdelibs ==
KDELIBS requires an out-of-source build, that is why it is more complicated to build:
cd
git clone kde:kdelibs
mkdir kdelibs-build
cd kdelibs-build
cmakekdelibs
Verify it has been correctly installed - the following must be possible:
kde4-config --prefix
/usr/local

== kactivities ==
kactivities is needed for kde-workspace.
cd
git clone kde:kactivities
cd kactivities
cmakekde

== kdebase ==
cd
git clone kde:kde-baseapps
git clone kde:konsole
git clone kde:kde-workspace
git clone kde:kde-runtime
cd kde-baseapps
cmakekde
cd
cd konsole
cmakekde
cd
cd kde-workspace
cmakekde
cd
cd kde-runtime
cmakekde

= Config =
First allow root login. You will need it as you do not have another login:
sed -i "s/AllowRootLogin.*/AllowRootLogin=true/g" /usr/local/share/config/kdm/kdmrc
Now stop your running display manager:
/etc/init.d/xdm stop
And start your self-compiled display manager:
kdm
To enable automated startup of your kdm, you need to change a SUSE-specific path in /etc/init.d/xdm:
KDM4_BIN=/usr/local/bin/kdm

Getting Started/Build/KDE4/on virtual machines

2012-02-12T13:15:41Z

Tstaerk: /* setup for SSH */

{{Infobox tutorial|time=3 hours|type=HowTo|distribution=SUSE Linux 12.1|happyreaders=2|unhappyreaders=0}}

This describes how to use a virtual machine for building the latest KDE from sources.

= Virtual Machine Setup =
Create a virtual machine, e.g. using [http://www.linuxintro.org/wiki/VMWare VMware Player]. Regarding harddisk: KDE 4 fits into 10 GB, however [[User:Tstaerk|I]] recommend 40GB, one partition. Regarding RAM: You will need at least 1GB ram for the virtual machine, of course more is better.

;You will need to set your SUSE CD as your virtual machine's cdrom.

== setup for SSH ==
To be able to log in to your VM using ssh, stop and disable the firewall:
rcSuSEfirewall2 stop
chkconfig SuSEfirewall2_setup off
chkconfig SuSEfirewall2_init off
/etc/init.d/sshd start
chkconfig sshd on
Inside the VM, install some needed packages:
yast -i libqt4-devel libsoprano-devel pcre-devel libxslt-devel libxml2-devel docbook-xsl-stylesheets git cmake

;Now it is time to do a snapshot or clone from your VM.
You will be able to return to this machine state whenever you want.

== a few more steps ==
Open a console as root
su -

== on an x64 distribution ==
If and only if you have a /lib64 path, you are on an x64 distribution.
Make sure you have the needed environment variables and alias set by having a file /root/.bashrc.
cd
cat >.bashrc<<EOF
export KDEDIR=/usr/local
alias cmakekde="cmake . -DCMAKE_INSTALL_PREFIX=\$KDEDIR -DLIB_SUFFIX=64 -D[[Development/CMake/Addons_for_KDE#Buildtypes|CMAKE_BUILD_TYPE]]=debugfull && make -j8 && make install"
alias cmakekdelibs="cmake ../kdelibs -DCMAKE_INSTALL_PREFIX=\$KDEDIR -DLIB_SUFFIX=64 -DCMAKE_BUILD_TYPE=debugfull && make -j8 && make install"
alias makeqt="./configure -dbus -openssl -plugin-sql-mysql -libdir /usr/lib64 -prefix /usr && make -j8 && make install"
export QTDIR=/usr
EOF
cat >.gitconfig<<EOF
[url "git://anongit.kde.org/"]
insteadOf = kde:
[url "ssh://git@git.kde.org/"]
pushInsteadOf = kde:
EOF
Now activate this file
. /root/.bashrc

== on another distribution (incl 32bit)==
Make sure you have the needed environment variables and alias set by having a file /root/.bashrc.
cd
cat >.bashrc<<EOF
export KDEDIR=/usr/local
alias cmakekde="cmake . -DCMAKE_INSTALL_PREFIX=\$KDEDIR -DCMAKE_BUILD_TYPE=debugfull && make -j8 && make install"
alias cmakekdelibs="cmake ../kdelibs -DCMAKE_INSTALL_PREFIX=\$KDEDIR -DCMAKE_BUILD_TYPE=debugfull && make -j8 && make install"
alias makeqt="./configure -dbus -openssl -plugin-sql-mysql -prefix /usr && make -j8 && make install"
export QTDIR=/usr
EOF
cat >.gitconfig<<EOF
[url "git://anongit.kde.org/"]
insteadOf = kde:
[url "ssh://git@git.kde.org/"]
pushInsteadOf = kde:
EOF
Now activate this file
. /root/.bashrc

= Aquire and Build KDE as root =
If something fails you may need to make clean.

== automoc ==
automoc is needed for akonadi.
cd
git clone kde:automoc
cd automoc
cmakekde

== akonadi ==
Akonadi keeps personal information management data in a mysql database. It is needed for KDEPIMLIBS.
cd
git clone kde:akonadi
cd akonadi
cmakekde

== libattica ==
cd
git clone kde:attica
cd attica
cmakekde

== dbusmenuqt ==
cd
git clone git://gitorious.org/dbusmenu/dbusmenu-qt.git
cd dbusmenu-qt
cmakekde

== shared desktop ontologies ==
shared desktop ontologies is needed by kdepimlibs in order to build Nepomuk (which is a part of kdelibs)
cd
wget http://downloads.sourceforge.net/project/oscaf/shared-desktop-ontologies/0.8/shared-desktop-ontologies-0.8.0.tar.bz2
bunzip2 shared-desktop-ontologies-0.8.0.tar.bz2
tar xvf shared-desktop-ontologies-0.8.0.tar
cd shared-desktop-ontologies-0.8.0/
cmake . && make && make install

== phonon ==
Phonon is needed for kdebase-runtime
cd
git clone git://anongit.kde.org/phonon
cd phonon
cmakekde

== kdelibs ==
KDELIBS requires an out-of-source build, that is why it is more complicated to build:
cd
git clone kde:kdelibs
mkdir kdelibs-build
cd kdelibs-build
cmakekdelibs
Verify it has been correctly installed - the following must be possible:
kde4-config --prefix
/usr/local

== kactivities ==
kactivities is needed for kde-workspace.
cd
git clone kde:kactivities
cd kactivities
cmakekde

== kdebase ==
cd
git clone kde:kde-baseapps
git clone kde:konsole
git clone kde:kde-workspace
git clone kde:kde-runtime
cd kde-baseapps
cmakekde
cd
cd konsole
cmakekde
cd
cd kde-workspace
cmakekde
cd
cd kde-runtime
cmakekde

= Config =
First allow root login. You will need it as you do not have another login:
sed -i "s/AllowRootLogin.*/AllowRootLogin=true/g" /usr/local/share/config/kdm/kdmrc
Now stop your running display manager:
/etc/init.d/xdm stop
And start your self-compiled display manager:
kdm
To enable automated startup of your kdm, you need to change a SUSE-specific path in /etc/init.d/xdm:
KDM4_BIN=/usr/local/bin/kdm

Getting Started/Build/KDE4/on virtual machines

2012-02-12T13:13:24Z

Tstaerk: /* setup for SSH */

{{Infobox tutorial|time=3 hours|type=HowTo|distribution=SUSE Linux 12.1|happyreaders=2|unhappyreaders=0}}

This describes how to use a virtual machine for building the latest KDE from sources.

= Virtual Machine Setup =
Create a virtual machine, e.g. using [http://www.linuxintro.org/wiki/VMWare VMware Player]. Regarding harddisk: KDE 4 fits into 10 GB, however [[User:Tstaerk|I]] recommend 40GB, one partition. Regarding RAM: You will need at least 1GB ram for the virtual machine, of course more is better.

;You will need to set your SUSE CD as your virtual machine's cdrom.

== setup for SSH ==
To be able to log in to your VM using ssh, stop and disable the firewall:
rcSuSEfirewall2 stop
chkconfig SuSEfirewall2_setup off
chkconfig SuSEfirewall2_init off
/etc/init.d/sshd start
chkconfig sshd on
Inside the VM, install some needed packages:
yast -i libqt4-devel libsoprano-devel pcre-devel libxslt-devel libxml2-devel docbook-xsl-stylesheets git

;Now it is time to do a snapshot or clone from your VM.
You will be able to return to this machine state whenever you want.

== a few more steps ==
Open a console as root
su -

== on an x64 distribution ==
If and only if you have a /lib64 path, you are on an x64 distribution.
Make sure you have the needed environment variables and alias set by having a file /root/.bashrc.
cd
cat >.bashrc<<EOF
export KDEDIR=/usr/local
alias cmakekde="cmake . -DCMAKE_INSTALL_PREFIX=\$KDEDIR -DLIB_SUFFIX=64 -D[[Development/CMake/Addons_for_KDE#Buildtypes|CMAKE_BUILD_TYPE]]=debugfull && make -j8 && make install"
alias cmakekdelibs="cmake ../kdelibs -DCMAKE_INSTALL_PREFIX=\$KDEDIR -DLIB_SUFFIX=64 -DCMAKE_BUILD_TYPE=debugfull && make -j8 && make install"
alias makeqt="./configure -dbus -openssl -plugin-sql-mysql -libdir /usr/lib64 -prefix /usr && make -j8 && make install"
export QTDIR=/usr
EOF
cat >.gitconfig<<EOF
[url "git://anongit.kde.org/"]
insteadOf = kde:
[url "ssh://git@git.kde.org/"]
pushInsteadOf = kde:
EOF
Now activate this file
. /root/.bashrc

== on another distribution (incl 32bit)==
Make sure you have the needed environment variables and alias set by having a file /root/.bashrc.
cd
cat >.bashrc<<EOF
export KDEDIR=/usr/local
alias cmakekde="cmake . -DCMAKE_INSTALL_PREFIX=\$KDEDIR -DCMAKE_BUILD_TYPE=debugfull && make -j8 && make install"
alias cmakekdelibs="cmake ../kdelibs -DCMAKE_INSTALL_PREFIX=\$KDEDIR -DCMAKE_BUILD_TYPE=debugfull && make -j8 && make install"
alias makeqt="./configure -dbus -openssl -plugin-sql-mysql -prefix /usr && make -j8 && make install"
export QTDIR=/usr
EOF
cat >.gitconfig<<EOF
[url "git://anongit.kde.org/"]
insteadOf = kde:
[url "ssh://git@git.kde.org/"]
pushInsteadOf = kde:
EOF
Now activate this file
. /root/.bashrc

= Aquire and Build KDE as root =
If something fails you may need to make clean.

== automoc ==
automoc is needed for akonadi.
cd
git clone kde:automoc
cd automoc
cmakekde

== akonadi ==
Akonadi keeps personal information management data in a mysql database. It is needed for KDEPIMLIBS.
cd
git clone kde:akonadi
cd akonadi
cmakekde

== libattica ==
cd
git clone kde:attica
cd attica
cmakekde

== dbusmenuqt ==
cd
git clone git://gitorious.org/dbusmenu/dbusmenu-qt.git
cd dbusmenu-qt
cmakekde

== shared desktop ontologies ==
shared desktop ontologies is needed by kdepimlibs in order to build Nepomuk (which is a part of kdelibs)
cd
wget http://downloads.sourceforge.net/project/oscaf/shared-desktop-ontologies/0.8/shared-desktop-ontologies-0.8.0.tar.bz2
bunzip2 shared-desktop-ontologies-0.8.0.tar.bz2
tar xvf shared-desktop-ontologies-0.8.0.tar
cd shared-desktop-ontologies-0.8.0/
cmake . && make && make install

== phonon ==
Phonon is needed for kdebase-runtime
cd
git clone git://anongit.kde.org/phonon
cd phonon
cmakekde

== kdelibs ==
KDELIBS requires an out-of-source build, that is why it is more complicated to build:
cd
git clone kde:kdelibs
mkdir kdelibs-build
cd kdelibs-build
cmakekdelibs
Verify it has been correctly installed - the following must be possible:
kde4-config --prefix
/usr/local

== kactivities ==
kactivities is needed for kde-workspace.
cd
git clone kde:kactivities
cd kactivities
cmakekde

== kdebase ==
cd
git clone kde:kde-baseapps
git clone kde:konsole
git clone kde:kde-workspace
git clone kde:kde-runtime
cd kde-baseapps
cmakekde
cd
cd konsole
cmakekde
cd
cd kde-workspace
cmakekde
cd
cd kde-runtime
cmakekde

= Config =
First allow root login. You will need it as you do not have another login:
sed -i "s/AllowRootLogin.*/AllowRootLogin=true/g" /usr/local/share/config/kdm/kdmrc
Now stop your running display manager:
/etc/init.d/xdm stop
And start your self-compiled display manager:
kdm
To enable automated startup of your kdm, you need to change a SUSE-specific path in /etc/init.d/xdm:
KDM4_BIN=/usr/local/bin/kdm

Getting Started/Build/KDE4/on virtual machines

2012-02-12T12:16:36Z

Tstaerk: /* setup for SSH */

{{Infobox tutorial|time=3 hours|type=HowTo|distribution=SUSE Linux 12.1|happyreaders=2|unhappyreaders=0}}

This describes how to use a virtual machine for building the latest KDE from sources.

= Virtual Machine Setup =
Create a virtual machine, e.g. using [http://www.linuxintro.org/wiki/VMWare VMware Player]. Regarding harddisk: KDE 4 fits into 10 GB, however [[User:Tstaerk|I]] recommend 40GB, one partition. Regarding RAM: You will need at least 1GB ram for the virtual machine, of course more is better.

;You will need to set your SUSE CD as your virtual machine's cdrom.

== setup for SSH ==
To be able to log in to your VM using ssh, stop and disable the firewall:
rcSuSEfirewall2 stop
chkconfig SuSEfirewall2_setup off
chkconfig SuSEfirewall2_init off
/etc/init.d/sshd start
chkconfig sshd on
Inside the VM, install some needed packages:
yast -i libqt4-devel libsoprano-devel pcre-devel libxslt-devel libxml2-devel docbook-xsl-stylesheets

;Now it is time to do a snapshot or clone from your VM.
You will be able to return to this machine state whenever you want.

== a few more steps ==
Open a console as root
su -

== on an x64 distribution ==
If and only if you have a /lib64 path, you are on an x64 distribution.
Make sure you have the needed environment variables and alias set by having a file /root/.bashrc.
cd
cat >.bashrc<<EOF
export KDEDIR=/usr/local
alias cmakekde="cmake . -DCMAKE_INSTALL_PREFIX=\$KDEDIR -DLIB_SUFFIX=64 -D[[Development/CMake/Addons_for_KDE#Buildtypes|CMAKE_BUILD_TYPE]]=debugfull && make -j8 && make install"
alias cmakekdelibs="cmake ../kdelibs -DCMAKE_INSTALL_PREFIX=\$KDEDIR -DLIB_SUFFIX=64 -DCMAKE_BUILD_TYPE=debugfull && make -j8 && make install"
alias makeqt="./configure -dbus -openssl -plugin-sql-mysql -libdir /usr/lib64 -prefix /usr && make -j8 && make install"
export QTDIR=/usr
EOF
cat >.gitconfig<<EOF
[url "git://anongit.kde.org/"]
insteadOf = kde:
[url "ssh://git@git.kde.org/"]
pushInsteadOf = kde:
EOF
Now activate this file
. /root/.bashrc

== on another distribution (incl 32bit)==
Make sure you have the needed environment variables and alias set by having a file /root/.bashrc.
cd
cat >.bashrc<<EOF
export KDEDIR=/usr/local
alias cmakekde="cmake . -DCMAKE_INSTALL_PREFIX=\$KDEDIR -DCMAKE_BUILD_TYPE=debugfull && make -j8 && make install"
alias cmakekdelibs="cmake ../kdelibs -DCMAKE_INSTALL_PREFIX=\$KDEDIR -DCMAKE_BUILD_TYPE=debugfull && make -j8 && make install"
alias makeqt="./configure -dbus -openssl -plugin-sql-mysql -prefix /usr && make -j8 && make install"
export QTDIR=/usr
EOF
cat >.gitconfig<<EOF
[url "git://anongit.kde.org/"]
insteadOf = kde:
[url "ssh://git@git.kde.org/"]
pushInsteadOf = kde:
EOF
Now activate this file
. /root/.bashrc

= Aquire and Build KDE as root =
If something fails you may need to make clean.

== automoc ==
automoc is needed for akonadi.
cd
git clone kde:automoc
cd automoc
cmakekde

== akonadi ==
Akonadi keeps personal information management data in a mysql database. It is needed for KDEPIMLIBS.
cd
git clone kde:akonadi
cd akonadi
cmakekde

== libattica ==
cd
git clone kde:attica
cd attica
cmakekde

== dbusmenuqt ==
cd
git clone git://gitorious.org/dbusmenu/dbusmenu-qt.git
cd dbusmenu-qt
cmakekde

== shared desktop ontologies ==
shared desktop ontologies is needed by kdepimlibs in order to build Nepomuk (which is a part of kdelibs)
cd
wget http://downloads.sourceforge.net/project/oscaf/shared-desktop-ontologies/0.8/shared-desktop-ontologies-0.8.0.tar.bz2
bunzip2 shared-desktop-ontologies-0.8.0.tar.bz2
tar xvf shared-desktop-ontologies-0.8.0.tar
cd shared-desktop-ontologies-0.8.0/
cmake . && make && make install

== phonon ==
Phonon is needed for kdebase-runtime
cd
git clone git://anongit.kde.org/phonon
cd phonon
cmakekde

== kdelibs ==
KDELIBS requires an out-of-source build, that is why it is more complicated to build:
cd
git clone kde:kdelibs
mkdir kdelibs-build
cd kdelibs-build
cmakekdelibs
Verify it has been correctly installed - the following must be possible:
kde4-config --prefix
/usr/local

== kactivities ==
kactivities is needed for kde-workspace.
cd
git clone kde:kactivities
cd kactivities
cmakekde

== kdebase ==
cd
git clone kde:kde-baseapps
git clone kde:konsole
git clone kde:kde-workspace
git clone kde:kde-runtime
cd kde-baseapps
cmakekde
cd
cd konsole
cmakekde
cd
cd kde-workspace
cmakekde
cd
cd kde-runtime
cmakekde

= Config =
First allow root login. You will need it as you do not have another login:
sed -i "s/AllowRootLogin.*/AllowRootLogin=true/g" /usr/local/share/config/kdm/kdmrc
Now stop your running display manager:
/etc/init.d/xdm stop
And start your self-compiled display manager:
kdm
To enable automated startup of your kdm, you need to change a SUSE-specific path in /etc/init.d/xdm:
KDM4_BIN=/usr/local/bin/kdm

Getting Started/Build/KDE4/on virtual machines

2012-02-12T12:11:56Z

Tstaerk: /* setup for SSH */

{{Infobox tutorial|time=3 hours|type=HowTo|distribution=SUSE Linux 12.1|happyreaders=2|unhappyreaders=0}}

This describes how to use a virtual machine for building the latest KDE from sources.

= Virtual Machine Setup =
Create a virtual machine, e.g. using [http://www.linuxintro.org/wiki/VMWare VMware Player]. Regarding harddisk: KDE 4 fits into 10 GB, however [[User:Tstaerk|I]] recommend 40GB, one partition. Regarding RAM: You will need at least 1GB ram for the virtual machine, of course more is better.

;You will need to set your SUSE CD as your virtual machine's cdrom.

== setup for SSH ==
To be able to log in to your VM using ssh, stop and disable the firewall:
rcSuSEfirewall2 stop
chkconfig SuSEfirewall2_setup off
chkconfig SuSEfirewall2_init off
/etc/init.d/sshd start
chkconfig sshd on
Inside the VM, install some needed packages:
yast -i libqt4-devel libsoprano-devel pcre-devel libxslt-devel libxml2-devel

;Now it is time to do a snapshot or clone from your VM.
You will be able to return to this machine state whenever you want.

== a few more steps ==
Open a console as root
su -

== on an x64 distribution ==
If and only if you have a /lib64 path, you are on an x64 distribution.
Make sure you have the needed environment variables and alias set by having a file /root/.bashrc.
cd
cat >.bashrc<<EOF
export KDEDIR=/usr/local
alias cmakekde="cmake . -DCMAKE_INSTALL_PREFIX=\$KDEDIR -DLIB_SUFFIX=64 -D[[Development/CMake/Addons_for_KDE#Buildtypes|CMAKE_BUILD_TYPE]]=debugfull && make -j8 && make install"
alias cmakekdelibs="cmake ../kdelibs -DCMAKE_INSTALL_PREFIX=\$KDEDIR -DLIB_SUFFIX=64 -DCMAKE_BUILD_TYPE=debugfull && make -j8 && make install"
alias makeqt="./configure -dbus -openssl -plugin-sql-mysql -libdir /usr/lib64 -prefix /usr && make -j8 && make install"
export QTDIR=/usr
EOF
cat >.gitconfig<<EOF
[url "git://anongit.kde.org/"]
insteadOf = kde:
[url "ssh://git@git.kde.org/"]
pushInsteadOf = kde:
EOF
Now activate this file
. /root/.bashrc

== on another distribution (incl 32bit)==
Make sure you have the needed environment variables and alias set by having a file /root/.bashrc.
cd
cat >.bashrc<<EOF
export KDEDIR=/usr/local
alias cmakekde="cmake . -DCMAKE_INSTALL_PREFIX=\$KDEDIR -DCMAKE_BUILD_TYPE=debugfull && make -j8 && make install"
alias cmakekdelibs="cmake ../kdelibs -DCMAKE_INSTALL_PREFIX=\$KDEDIR -DCMAKE_BUILD_TYPE=debugfull && make -j8 && make install"
alias makeqt="./configure -dbus -openssl -plugin-sql-mysql -prefix /usr && make -j8 && make install"
export QTDIR=/usr
EOF
cat >.gitconfig<<EOF
[url "git://anongit.kde.org/"]
insteadOf = kde:
[url "ssh://git@git.kde.org/"]
pushInsteadOf = kde:
EOF
Now activate this file
. /root/.bashrc

= Aquire and Build KDE as root =
If something fails you may need to make clean.

== automoc ==
automoc is needed for akonadi.
cd
git clone kde:automoc
cd automoc
cmakekde

== akonadi ==
Akonadi keeps personal information management data in a mysql database. It is needed for KDEPIMLIBS.
cd
git clone kde:akonadi
cd akonadi
cmakekde

== libattica ==
cd
git clone kde:attica
cd attica
cmakekde

== dbusmenuqt ==
cd
git clone git://gitorious.org/dbusmenu/dbusmenu-qt.git
cd dbusmenu-qt
cmakekde

== shared desktop ontologies ==
shared desktop ontologies is needed by kdepimlibs in order to build Nepomuk (which is a part of kdelibs)
cd
wget http://downloads.sourceforge.net/project/oscaf/shared-desktop-ontologies/0.8/shared-desktop-ontologies-0.8.0.tar.bz2
bunzip2 shared-desktop-ontologies-0.8.0.tar.bz2
tar xvf shared-desktop-ontologies-0.8.0.tar
cd shared-desktop-ontologies-0.8.0/
cmake . && make && make install

== phonon ==
Phonon is needed for kdebase-runtime
cd
git clone git://anongit.kde.org/phonon
cd phonon
cmakekde

== kdelibs ==
KDELIBS requires an out-of-source build, that is why it is more complicated to build:
cd
git clone kde:kdelibs
mkdir kdelibs-build
cd kdelibs-build
cmakekdelibs
Verify it has been correctly installed - the following must be possible:
kde4-config --prefix
/usr/local

== kactivities ==
kactivities is needed for kde-workspace.
cd
git clone kde:kactivities
cd kactivities
cmakekde

== kdebase ==
cd
git clone kde:kde-baseapps
git clone kde:konsole
git clone kde:kde-workspace
git clone kde:kde-runtime
cd kde-baseapps
cmakekde
cd
cd konsole
cmakekde
cd
cd kde-workspace
cmakekde
cd
cd kde-runtime
cmakekde

= Config =
First allow root login. You will need it as you do not have another login:
sed -i "s/AllowRootLogin.*/AllowRootLogin=true/g" /usr/local/share/config/kdm/kdmrc
Now stop your running display manager:
/etc/init.d/xdm stop
And start your self-compiled display manager:
kdm
To enable automated startup of your kdm, you need to change a SUSE-specific path in /etc/init.d/xdm:
KDM4_BIN=/usr/local/bin/kdm

Getting Started/Build/KDE4/on virtual machines

2012-02-12T12:10:25Z

Tstaerk: /* setup for SSH */

{{Infobox tutorial|time=3 hours|type=HowTo|distribution=SUSE Linux 12.1|happyreaders=2|unhappyreaders=0}}

This describes how to use a virtual machine for building the latest KDE from sources.

= Virtual Machine Setup =
Create a virtual machine, e.g. using [http://www.linuxintro.org/wiki/VMWare VMware Player]. Regarding harddisk: KDE 4 fits into 10 GB, however [[User:Tstaerk|I]] recommend 40GB, one partition. Regarding RAM: You will need at least 1GB ram for the virtual machine, of course more is better.

;You will need to set your SUSE CD as your virtual machine's cdrom.

== setup for SSH ==
To be able to log in to your VM using ssh, stop and disable the firewall:
rcSuSEfirewall2 stop
chkconfig SuSEfirewall2_setup off
chkconfig SuSEfirewall2_init off
/etc/init.d/sshd start
chkconfig sshd on
Inside the VM, install some needed packages:
yast -i libqt4-devel libsoprano-devel pcre-devel

;Now it is time to do a snapshot or clone from your VM.
You will be able to return to this machine state whenever you want.

== a few more steps ==
Open a console as root
su -

== on an x64 distribution ==
If and only if you have a /lib64 path, you are on an x64 distribution.
Make sure you have the needed environment variables and alias set by having a file /root/.bashrc.
cd
cat >.bashrc<<EOF
export KDEDIR=/usr/local
alias cmakekde="cmake . -DCMAKE_INSTALL_PREFIX=\$KDEDIR -DLIB_SUFFIX=64 -D[[Development/CMake/Addons_for_KDE#Buildtypes|CMAKE_BUILD_TYPE]]=debugfull && make -j8 && make install"
alias cmakekdelibs="cmake ../kdelibs -DCMAKE_INSTALL_PREFIX=\$KDEDIR -DLIB_SUFFIX=64 -DCMAKE_BUILD_TYPE=debugfull && make -j8 && make install"
alias makeqt="./configure -dbus -openssl -plugin-sql-mysql -libdir /usr/lib64 -prefix /usr && make -j8 && make install"
export QTDIR=/usr
EOF
cat >.gitconfig<<EOF
[url "git://anongit.kde.org/"]
insteadOf = kde:
[url "ssh://git@git.kde.org/"]
pushInsteadOf = kde:
EOF
Now activate this file
. /root/.bashrc

== on another distribution (incl 32bit)==
Make sure you have the needed environment variables and alias set by having a file /root/.bashrc.
cd
cat >.bashrc<<EOF
export KDEDIR=/usr/local
alias cmakekde="cmake . -DCMAKE_INSTALL_PREFIX=\$KDEDIR -DCMAKE_BUILD_TYPE=debugfull && make -j8 && make install"
alias cmakekdelibs="cmake ../kdelibs -DCMAKE_INSTALL_PREFIX=\$KDEDIR -DCMAKE_BUILD_TYPE=debugfull && make -j8 && make install"
alias makeqt="./configure -dbus -openssl -plugin-sql-mysql -prefix /usr && make -j8 && make install"
export QTDIR=/usr
EOF
cat >.gitconfig<<EOF
[url "git://anongit.kde.org/"]
insteadOf = kde:
[url "ssh://git@git.kde.org/"]
pushInsteadOf = kde:
EOF
Now activate this file
. /root/.bashrc

= Aquire and Build KDE as root =
If something fails you may need to make clean.

== automoc ==
automoc is needed for akonadi.
cd
git clone kde:automoc
cd automoc
cmakekde

== akonadi ==
Akonadi keeps personal information management data in a mysql database. It is needed for KDEPIMLIBS.
cd
git clone kde:akonadi
cd akonadi
cmakekde

== libattica ==
cd
git clone kde:attica
cd attica
cmakekde

== dbusmenuqt ==
cd
git clone git://gitorious.org/dbusmenu/dbusmenu-qt.git
cd dbusmenu-qt
cmakekde

== shared desktop ontologies ==
shared desktop ontologies is needed by kdepimlibs in order to build Nepomuk (which is a part of kdelibs)
cd
wget http://downloads.sourceforge.net/project/oscaf/shared-desktop-ontologies/0.8/shared-desktop-ontologies-0.8.0.tar.bz2
bunzip2 shared-desktop-ontologies-0.8.0.tar.bz2
tar xvf shared-desktop-ontologies-0.8.0.tar
cd shared-desktop-ontologies-0.8.0/
cmake . && make && make install

== phonon ==
Phonon is needed for kdebase-runtime
cd
git clone git://anongit.kde.org/phonon
cd phonon
cmakekde

== kdelibs ==
KDELIBS requires an out-of-source build, that is why it is more complicated to build:
cd
git clone kde:kdelibs
mkdir kdelibs-build
cd kdelibs-build
cmakekdelibs
Verify it has been correctly installed - the following must be possible:
kde4-config --prefix
/usr/local

== kactivities ==
kactivities is needed for kde-workspace.
cd
git clone kde:kactivities
cd kactivities
cmakekde

== kdebase ==
cd
git clone kde:kde-baseapps
git clone kde:konsole
git clone kde:kde-workspace
git clone kde:kde-runtime
cd kde-baseapps
cmakekde
cd
cd konsole
cmakekde
cd
cd kde-workspace
cmakekde
cd
cd kde-runtime
cmakekde

= Config =
First allow root login. You will need it as you do not have another login:
sed -i "s/AllowRootLogin.*/AllowRootLogin=true/g" /usr/local/share/config/kdm/kdmrc
Now stop your running display manager:
/etc/init.d/xdm stop
And start your self-compiled display manager:
kdm
To enable automated startup of your kdm, you need to change a SUSE-specific path in /etc/init.d/xdm:
KDM4_BIN=/usr/local/bin/kdm

Getting Started/Build/KDE4/on virtual machines

2012-02-12T09:54:26Z

Tstaerk:

{{Infobox tutorial|time=3 hours|type=HowTo|distribution=SUSE Linux 12.1|happyreaders=2|unhappyreaders=0}}

This describes how to use a virtual machine for building the latest KDE from sources.

= Virtual Machine Setup =
Create a virtual machine, e.g. using [http://www.linuxintro.org/wiki/VMWare VMware Player]. Regarding harddisk: KDE 4 fits into 10 GB, however [[User:Tstaerk|I]] recommend 40GB, one partition. Regarding RAM: You will need at least 1GB ram for the virtual machine, of course more is better.

;You will need to set your SUSE CD as your virtual machine's cdrom.

== setup for SSH ==
To be able to log in to your VM using ssh, stop and disable the firewall:
rcSuSEfirewall2 stop
chkconfig SuSEfirewall2_setup off
chkconfig SuSEfirewall2_init off
/etc/init.d/sshd start
chkconfig sshd on
Inside the VM, install some needed packages:
yast -i libqt4-devel libsoprano-devel

;Now it is time to do a snapshot or clone from your VM.
You will be able to return to this machine state whenever you want.

== a few more steps ==
Open a console as root
su -

== on an x64 distribution ==
If and only if you have a /lib64 path, you are on an x64 distribution.
Make sure you have the needed environment variables and alias set by having a file /root/.bashrc.
cd
cat >.bashrc<<EOF
export KDEDIR=/usr/local
alias cmakekde="cmake . -DCMAKE_INSTALL_PREFIX=\$KDEDIR -DLIB_SUFFIX=64 -D[[Development/CMake/Addons_for_KDE#Buildtypes|CMAKE_BUILD_TYPE]]=debugfull && make -j8 && make install"
alias cmakekdelibs="cmake ../kdelibs -DCMAKE_INSTALL_PREFIX=\$KDEDIR -DLIB_SUFFIX=64 -DCMAKE_BUILD_TYPE=debugfull && make -j8 && make install"
alias makeqt="./configure -dbus -openssl -plugin-sql-mysql -libdir /usr/lib64 -prefix /usr && make -j8 && make install"
export QTDIR=/usr
EOF
cat >.gitconfig<<EOF
[url "git://anongit.kde.org/"]
insteadOf = kde:
[url "ssh://git@git.kde.org/"]
pushInsteadOf = kde:
EOF
Now activate this file
. /root/.bashrc

== on another distribution (incl 32bit)==
Make sure you have the needed environment variables and alias set by having a file /root/.bashrc.
cd
cat >.bashrc<<EOF
export KDEDIR=/usr/local
alias cmakekde="cmake . -DCMAKE_INSTALL_PREFIX=\$KDEDIR -DCMAKE_BUILD_TYPE=debugfull && make -j8 && make install"
alias cmakekdelibs="cmake ../kdelibs -DCMAKE_INSTALL_PREFIX=\$KDEDIR -DCMAKE_BUILD_TYPE=debugfull && make -j8 && make install"
alias makeqt="./configure -dbus -openssl -plugin-sql-mysql -prefix /usr && make -j8 && make install"
export QTDIR=/usr
EOF
cat >.gitconfig<<EOF
[url "git://anongit.kde.org/"]
insteadOf = kde:
[url "ssh://git@git.kde.org/"]
pushInsteadOf = kde:
EOF
Now activate this file
. /root/.bashrc

= Aquire and Build KDE as root =
If something fails you may need to make clean.

== automoc ==
automoc is needed for akonadi.
cd
git clone kde:automoc
cd automoc
cmakekde

== akonadi ==
Akonadi keeps personal information management data in a mysql database. It is needed for KDEPIMLIBS.
cd
git clone kde:akonadi
cd akonadi
cmakekde

== libattica ==
cd
git clone kde:attica
cd attica
cmakekde

== dbusmenuqt ==
cd
git clone git://gitorious.org/dbusmenu/dbusmenu-qt.git
cd dbusmenu-qt
cmakekde

== shared desktop ontologies ==
shared desktop ontologies is needed by kdepimlibs in order to build Nepomuk (which is a part of kdelibs)
cd
wget http://downloads.sourceforge.net/project/oscaf/shared-desktop-ontologies/0.8/shared-desktop-ontologies-0.8.0.tar.bz2
bunzip2 shared-desktop-ontologies-0.8.0.tar.bz2
tar xvf shared-desktop-ontologies-0.8.0.tar
cd shared-desktop-ontologies-0.8.0/
cmake . && make && make install

== phonon ==
Phonon is needed for kdebase-runtime
cd
git clone git://anongit.kde.org/phonon
cd phonon
cmakekde

== kdelibs ==
KDELIBS requires an out-of-source build, that is why it is more complicated to build:
cd
git clone kde:kdelibs
mkdir kdelibs-build
cd kdelibs-build
cmakekdelibs
Verify it has been correctly installed - the following must be possible:
kde4-config --prefix
/usr/local

== kactivities ==
kactivities is needed for kde-workspace.
cd
git clone kde:kactivities
cd kactivities
cmakekde

== kdebase ==
cd
git clone kde:kde-baseapps
git clone kde:konsole
git clone kde:kde-workspace
git clone kde:kde-runtime
cd kde-baseapps
cmakekde
cd
cd konsole
cmakekde
cd
cd kde-workspace
cmakekde
cd
cd kde-runtime
cmakekde

= Config =
First allow root login. You will need it as you do not have another login:
sed -i "s/AllowRootLogin.*/AllowRootLogin=true/g" /usr/local/share/config/kdm/kdmrc
Now stop your running display manager:
/etc/init.d/xdm stop
And start your self-compiled display manager:
kdm
To enable automated startup of your kdm, you need to change a SUSE-specific path in /etc/init.d/xdm:
KDM4_BIN=/usr/local/bin/kdm

Getting Started/Build/kdesrc-build

2012-02-11T18:09:48Z

Tstaerk: /* Setup the configuration */

{{Template:I18n/Language Navigation Bar|Getting_Started/Build/kdesrc-build}}

{{note|It is possible to build KDE 3 using older versions of kdesrc-build, but this is not described here.}}

== Building KDE using the kdesrc-build tool ==

=== Introduction to kdesrc-build ===

[http://kdesrc-build.kde.org/ kdesrc-build] (formerly kdesvn-build) is a tool to allow users and developers to easily download and build the latest versions of the KDE Software Compilation (KDE SC) from the KDE source code repositories. It automates the following tasks and more:

* Performing the initial checkout.
* Handling updates for modules that are already checked out.
* Setting up the build system for the module.
* Performing the build and install.
* Specifying your CMake options or configure flags (so you don't have to remember them every time).
* Logging build errors so you can review them easier for troubleshooting.

It is not the end-all for your troubles building KDE, [[../Troubleshooting|Troubleshooting]] still applies. Many errors that occur using other methods occur here too, you read the log files that are stored for you.

=== Why use kdesrc-build? ===

So why use kdesrc-build? There are several reasons you may like to use it:

# Less manual editing of commands. Instead of having to remember to add the correct options to the cmake command line or configure command, you can setup the options once and then kdesrc-build will use your settings from then on, saving you from wasting time because you forgot to enable a setting.
# Command logging to help debug build failures. kdesrc-build logs all command outputs to a file. This has several advantages:
## When a module fails to build, you already have the error output saved to disk, ready to be viewed and compared with other error messages to aid debugging.
## Quieter output. Even with CMake, the output of Qt or a KDE SC module build can be extensive. kdesrc-build does not show the details of a module build (but will show the progress), instead an overview of the build process is displayed.
# It's just easier. Instead of having to learn how to use the Subversion and git tools, and how to setup a KDE build system, you can specify what modules you want build, where to install them to, and any other options you want and then have kdesrc-build actually do it, even while you're away from the computer or busy doing other things.
# It's easy to step in yourself. kdesrc-build uses a standard source and build directory layout, and calls the same commands you would. So kdesrc-build will not interfere with you performing the build or editing the source yourself if you so choose.

=== Setting up ===

==== Prerequisites ====
kdesrc-build is fairly easy to install and setup, but you also need to have the right software installed to build KDE. The requirements to build KDE are available as follows:

* KDE 4: [[../Requirements|KDE 4 Requirements]]

kdesrc-build requires Perl 5.8 or higher. It is installed by default with most distributions, and is included in the link above. Check your version of Perl with:
<syntaxhighlight lang="text">perl -v</syntaxhighlight>

You will also need [https://github.com/gisle/libwww-perl#readme libwww], a collection of Perl Internet-related modules.

{{note|kdesrc-build is developed on a Linux system, but it should work on the various BSD distributions as well (although GNU tools may be required).}}

==== Download and install kdesrc-build ====
Once your system is setup to be able to compile the KDE SC, you can download kdesrc-build from its website, [http://kdesrc-build.kde.org/ kdesrc-build.kde.org]. The file you download will contain (at least) the kdesrc-build script and a sample configuration file. Installing kdesrc-build is as simple as saving the file and making it executable. If you'd like, you can move it to a directory in your PATH, however for this example we'll put it into the KDE source directory that we use (~/kdesrc)

<syntaxhighlight lang="bash">
mkdir -p ~/kdesrc &&
cd ~/kdesrc &&
tar xjvf ~/path/to/kdesrc-build-1.14.1.tar.bz2 &&
cp kdesrc-build-1.14.1/kdesrc-build .
</syntaxhighlight>

Alternatively, the newest kdesrc-build script (and sample config file) can be pulled directly from git:
<syntaxhighlight lang="bash">
git clone git://anongit.kde.org/kdesrc-build.git ~/kdesrc
</syntaxhighlight>

==== Setup the configuration ====
Now you should [[Getting Started/Build/kdesrc-build-config|setup your configuration]]. For the most part the defaults in the included kdesrc-buildrc-sample should be sufficient.

<syntaxhighlight lang="bash">
cp ~/kdesrc/kdesrc-build-1.14.1/kdesrc-buildrc-sample ~/.kdesrc-buildrc
</syntaxhighlight>

Now you can start kdesrc-build using the commands
cd
./kdesrc-build

Now you can edit the configuration file ~/.kdesrc-buildrc

{{tip|Note that the config file's name begins with a leading ., making it a hidden file. You may need to show hidden files in Dolphin or Konqueror to find the configuration file to edit it. Or, you can edit the sample before copying it to ~/.kdesrc-buildrc.}}

Also, make sure that the modules you'll want to build are included. You'll want the following at the least:

* qt-copy, kdesupport, kdelibs, kdepimlibs, kdebase

Modules are built in the order they appear in your ~/.kdesrc-buildrc, so the first module should be qt-copy, kdelibs should be before any other KDE SC module, and so on.

{{note|The sample configuration file does include these modules by default, you won't need to make many changes unless you'd like to add some modules to the build by uncommenting them.}}

You may want to enable the make-install-prefix option if you are installing KDE SC or Qt to a directory that is not in your home directory. make-install-prefix allows you to run su or sudo during the make install process so you can install files as root, or set certain programs to execute with higher permissions (This is required for certain programs to execute properly).

<pre>module kdelibs
make-install-prefix sudo -S # sudo with no stdin
end module

module kdebase
make-install-prefix sudo -S
end module</pre>

If a module you'd like to build isn't already present, simply add

<pre>module <module-name>
end module</pre> at the end of the ~/.kdesrc-buildrc. <module-name> would be whatever the module is called in the software repository (for instance, kdemultimedia).

===== Git-based modules =====

Some KDE projects use the "git" source-control software instead of Subversion (as part of an ongoing migration to git). This includes software like Amarok and Konversation.

To build these modules in kdesrc-build, you just need to add a couple of lines to the module configuration. For example, konversation is developed in the Git repository at [https://projects.kde.org/projects/extragear/network/konversation/repository]. So you would just add a module (you can pick whatever name for the module you like, as long as it's not already used):

<pre>module konversation
repository git://anongit.kde.org/konversation
branch master
end module</pre>

In this case I selected the "master" branch since that is the default git branch.

Now whenever you build konversation, kdesrc-build will use git instead of Subversion.

==== Useful kdesrc-build commands ====
kdesrc-build is driven from the command line, so here's a guide to some of the more useful command line options:

<table cellpadding="2">
<tr>
<th>Option</th><th>Effect</th>
</tr>
<tr>
<td><tt><span style="white-space:nowrap;">[http://kdesrc-build.kde.org/documentation/cmdline.html#cmdline-pretend --pretend]</span></tt> (Short form <tt><span style="white-space:nowrap;">-p</span></tt>)</td>
<td>This option is like a dry run. kdesrc-build will process the options and its configuration like normal, and run through the build as normal, but instead of downloading or running the build will instead output what kdesrc-build would have done. You should always run with -p before running kdesrc-build to make sure it is doing what you expect.</td>
</tr>
<tr>
<td><tt>[http://kdesrc-build.kde.org/documentation/cmdline.html#cmdline-no-svn --no-svn]</tt> (Alt. form <tt>--no-src</tt>)</td><td>This option skips the source code update step. This is useful if you're running kdesrc-build again soon after the last update and don't want to wait to find out there were no changes.</td>
</tr>
<tr>
<td><tt>[http://kdesrc-build.kde.org/documentation/cmdline.html#cmdline-refresh-build --refresh-build]</tt></td><td>This option causes kdesrc-build to delete the current build information for the given modules and start building them again from scratch. This option takes a lot of time but gives the best chance of a successful build.</td>
</tr>
</table>

Any other non-option arguments on the command line are assumed to be modules to build (and are built in the order provided on the command line). If no modules are specified, all of the modules listed in the ~/.kdesrc-buildrc are built in the order listed in the file.

== Build ==
We're almost there. If you're happy with your settings then it's time to test out kdesrc-build. In theory things are as simple as running kdesrc-build and then coming back later. ;)

<syntaxhighlight lang="bash">
cd ~/kdesrc
./kdesrc-build
</syntaxhighlight>

You may want to test by building qt-copy first however.

<syntaxhighlight lang="bash">
cd ~/kdesrc
./kdesrc-build qt-copy
</syntaxhighlight>

{{tip|If you have the [http://www.gnu.org/software/screen/ GNU screen] program available then you should definitely use it to run kdesrc-build, as you can detach your kdesrc-build session and logout while kdesrc-build is still running.}}

If the build failed (kdesrc-build will error out with a nice bright red error message) then there are several possibilities:

# You are missing a key piece of required software (such as a development library)
# The KDE SC code being compiled is broken in some fashion to where it won't build. This is commonly due to newly committed code that worked on the developer's machine, or occasionally on Mondays (when incompatible changes are permitted to kdelibs).
# kdesrc-build is not setup properly. You may be trying to install to a directory that you have no permissions to access for instance, or you may have specified a system qtdir that does not exist.
# The module may depend on a newer version of qt-copy or kdelibs (or other module). In this case you'll have to run kdesrc-build to update the out-of-date module first.

How do you find out what the error was? The output of the failing command will be in the log directory. By default, all log output is in the {{path|log}} subdirectory of the KDE SC source directory. The log directory is laid out like this: {{path|log/date-run/module/output-file.log}}. To simplify finding the appropriate file, there are a couple of symlinks created:

{{path|log/latest}} always has the debugging output for the last time kdesrc-build was run (--pretend doesn't count toward this)
{{path|log/latest/<module>/error.log}} has the debugging output for the command that caused a module build to fail.

For instance if qt-copy just failed to build you could read the output like this:

<syntaxhighlight lang="bash">
cd ~/kderc
kwrite log/latest/qt-copy/error.log
</syntaxhighlight>

Replace kwrite with your preferred editor. Hopefully the output can guide you to resolving the problem. For instance, if the failure is a cmake output saying you're missing a library, install that library and try again. ;) For link errors you can try running a --refresh-build on the module (or if that doesn't work, required libraries like qt-copy and kdelibs).

If you're stumped by the error you may want to wait a day and try updating again, and hope that the reason for the error has been fixed. You can also try mailing the [http://www.kde.org/mailinglists/ kde-devel] mailing list to see if others know about the problem or have had similar issues.

== Running KDE ==

Assuming you got enough of the modules to build and install to have a working KDE installation, you'll still need to setup your environment correctly to run it. kdesrc-build doesn't help you out here (yet), so you should follow the instructions [[Getting_Started/Using_an_IDE_with_KDE4|here]].

Make sure to use the same paths as the ones you defined in .kdesrc-buildrc: for the KDEDIRS and KDEDIR variable use the setting of the "prefix" option (in the global section). For the QTDIR variable use the setting of the "qtdir" option.

== Keeping KDE up to date ==

Keeping your KDE installation up to date is as simple as running kdesrc-build again. Every kdesrc-build has these phases:

# Update the source code for all modules being built.
# Build and then install all the modules.

Old build directories are not deleted by default, so the build after a small update will not normally take as long as the initial build of a module. This is called "incremental make". However it may be necessary at times to perform a full rebuild due to inconsistencies between the build directory configuation and changes to the source directory. You can use the --refresh-build option to force a full rebuild.

For more information on how to take advantage of kdesrc-build, see the [http://kdesrc-build.kde.org/documentation online documentation] for kdesrc-build, which describes all of the module options and command line options available for kdesrc-build and gives tips on how to perform various useful tasks.

If you have any questions that are not answered please feel free to add them under the Discussion entry for this page and hopefully someone will be able to get the answer.

= See also =
* To browse the KDE Subversion repository, use [http://websvn.kde.org/trunk/KDE WebSVN].
* To browse any of the various KDE projects using git, you can go to [http://projects.kde.org KDE Git Projects] or to [http://gitweb.kde.org KDE Git Web].
* The Nokia Qt toolkit used by KDE can be browsed at [http://qt.gitorious.org/qt Nokia's Qt version on gitorious].

[[Category:Build_KDE]]
[[Category:Tutorial]]

Getting Started/Build/kdesrc-build

2012-02-11T17:14:24Z

Tstaerk: /* Setup the configuration */

{{Template:I18n/Language Navigation Bar|Getting_Started/Build/kdesrc-build}}

{{note|It is possible to build KDE 3 using older versions of kdesrc-build, but this is not described here.}}

== Building KDE using the kdesrc-build tool ==

=== Introduction to kdesrc-build ===

[http://kdesrc-build.kde.org/ kdesrc-build] (formerly kdesvn-build) is a tool to allow users and developers to easily download and build the latest versions of the KDE Software Compilation (KDE SC) from the KDE source code repositories. It automates the following tasks and more:

* Performing the initial checkout.
* Handling updates for modules that are already checked out.
* Setting up the build system for the module.
* Performing the build and install.
* Specifying your CMake options or configure flags (so you don't have to remember them every time).
* Logging build errors so you can review them easier for troubleshooting.

It is not the end-all for your troubles building KDE, [[../Troubleshooting|Troubleshooting]] still applies. Many errors that occur using other methods occur here too, you read the log files that are stored for you.

=== Why use kdesrc-build? ===

So why use kdesrc-build? There are several reasons you may like to use it:

# Less manual editing of commands. Instead of having to remember to add the correct options to the cmake command line or configure command, you can setup the options once and then kdesrc-build will use your settings from then on, saving you from wasting time because you forgot to enable a setting.
# Command logging to help debug build failures. kdesrc-build logs all command outputs to a file. This has several advantages:
## When a module fails to build, you already have the error output saved to disk, ready to be viewed and compared with other error messages to aid debugging.
## Quieter output. Even with CMake, the output of Qt or a KDE SC module build can be extensive. kdesrc-build does not show the details of a module build (but will show the progress), instead an overview of the build process is displayed.
# It's just easier. Instead of having to learn how to use the Subversion and git tools, and how to setup a KDE build system, you can specify what modules you want build, where to install them to, and any other options you want and then have kdesrc-build actually do it, even while you're away from the computer or busy doing other things.
# It's easy to step in yourself. kdesrc-build uses a standard source and build directory layout, and calls the same commands you would. So kdesrc-build will not interfere with you performing the build or editing the source yourself if you so choose.

=== Setting up ===

==== Prerequisites ====
kdesrc-build is fairly easy to install and setup, but you also need to have the right software installed to build KDE. The requirements to build KDE are available as follows:

* KDE 4: [[../Requirements|KDE 4 Requirements]]

kdesrc-build requires Perl 5.8 or higher. It is installed by default with most distributions, and is included in the link above. Check your version of Perl with:
<syntaxhighlight lang="text">perl -v</syntaxhighlight>

You will also need [https://github.com/gisle/libwww-perl#readme libwww], a collection of Perl Internet-related modules.

{{note|kdesrc-build is developed on a Linux system, but it should work on the various BSD distributions as well (although GNU tools may be required).}}

==== Download and install kdesrc-build ====
Once your system is setup to be able to compile the KDE SC, you can download kdesrc-build from its website, [http://kdesrc-build.kde.org/ kdesrc-build.kde.org]. The file you download will contain (at least) the kdesrc-build script and a sample configuration file. Installing kdesrc-build is as simple as saving the file and making it executable. If you'd like, you can move it to a directory in your PATH, however for this example we'll put it into the KDE source directory that we use (~/kdesrc)

<syntaxhighlight lang="bash">
mkdir -p ~/kdesrc &&
cd ~/kdesrc &&
tar xjvf ~/path/to/kdesrc-build-1.14.1.tar.bz2 &&
cp kdesrc-build-1.14.1/kdesrc-build .
</syntaxhighlight>

Alternatively, the newest kdesrc-build script (and sample config file) can be pulled directly from git:
<syntaxhighlight lang="bash">
git clone git://anongit.kde.org/kdesrc-build.git ~/kdesrc
</syntaxhighlight>

==== Setup the configuration ====
Now you should [[Getting Started/Build/kdesrc-build-config|setup your configuration]]. For the most part the defaults in the included kdesrc-buildrc-sample should be sufficient.

<syntaxhighlight lang="bash">
cp ~/kdesrc/kdesrc-build-1.14.1/kdesrc-buildrc-sample ~/.kdesrc-buildrc
# Now edit the ~/.kdesrc-buildrc
</syntaxhighlight>

{{tip|Note that the config file's name begins with a leading ., making it a hidden file. You may need to show hidden files in Dolphin or Konqueror to find the configuration file to edit it. Or, you can edit the sample before copying it to ~/.kdesrc-buildrc.}}

Also, make sure that the modules you'll want to build are included. You'll want the following at the least:

* qt-copy, kdesupport, kdelibs, kdepimlibs, kdebase

Modules are built in the order they appear in your ~/.kdesrc-buildrc, so the first module should be qt-copy, kdelibs should be before any other KDE SC module, and so on.

{{note|The sample configuration file does include these modules by default, you won't need to make many changes unless you'd like to add some modules to the build by uncommenting them.}}

You may want to enable the make-install-prefix option if you are installing KDE SC or Qt to a directory that is not in your home directory. make-install-prefix allows you to run su or sudo during the make install process so you can install files as root, or set certain programs to execute with higher permissions (This is required for certain programs to execute properly).

<pre>module kdelibs
make-install-prefix sudo -S # sudo with no stdin
end module

module kdebase
make-install-prefix sudo -S
end module</pre>

If a module you'd like to build isn't already present, simply add

<pre>module <module-name>
end module</pre> at the end of the ~/.kdesrc-buildrc. <module-name> would be whatever the module is called in the software repository (for instance, kdemultimedia).

===== Git-based modules =====

Some KDE projects use the "git" source-control software instead of Subversion (as part of an ongoing migration to git). This includes software like Amarok and Konversation.

To build these modules in kdesrc-build, you just need to add a couple of lines to the module configuration. For example, konversation is developed in the Git repository at [https://projects.kde.org/projects/extragear/network/konversation/repository]. So you would just add a module (you can pick whatever name for the module you like, as long as it's not already used):

<pre>module konversation
repository git://anongit.kde.org/konversation
branch master
end module</pre>

In this case I selected the "master" branch since that is the default git branch.

Now whenever you build konversation, kdesrc-build will use git instead of Subversion.

==== Useful kdesrc-build commands ====
kdesrc-build is driven from the command line, so here's a guide to some of the more useful command line options:

<table cellpadding="2">
<tr>
<th>Option</th><th>Effect</th>
</tr>
<tr>
<td><tt><span style="white-space:nowrap;">[http://kdesrc-build.kde.org/documentation/cmdline.html#cmdline-pretend --pretend]</span></tt> (Short form <tt><span style="white-space:nowrap;">-p</span></tt>)</td>
<td>This option is like a dry run. kdesrc-build will process the options and its configuration like normal, and run through the build as normal, but instead of downloading or running the build will instead output what kdesrc-build would have done. You should always run with -p before running kdesrc-build to make sure it is doing what you expect.</td>
</tr>
<tr>
<td><tt>[http://kdesrc-build.kde.org/documentation/cmdline.html#cmdline-no-svn --no-svn]</tt> (Alt. form <tt>--no-src</tt>)</td><td>This option skips the source code update step. This is useful if you're running kdesrc-build again soon after the last update and don't want to wait to find out there were no changes.</td>
</tr>
<tr>
<td><tt>[http://kdesrc-build.kde.org/documentation/cmdline.html#cmdline-refresh-build --refresh-build]</tt></td><td>This option causes kdesrc-build to delete the current build information for the given modules and start building them again from scratch. This option takes a lot of time but gives the best chance of a successful build.</td>
</tr>
</table>

Any other non-option arguments on the command line are assumed to be modules to build (and are built in the order provided on the command line). If no modules are specified, all of the modules listed in the ~/.kdesrc-buildrc are built in the order listed in the file.

== Build ==
We're almost there. If you're happy with your settings then it's time to test out kdesrc-build. In theory things are as simple as running kdesrc-build and then coming back later. ;)

<syntaxhighlight lang="bash">
cd ~/kdesrc
./kdesrc-build
</syntaxhighlight>

You may want to test by building qt-copy first however.

<syntaxhighlight lang="bash">
cd ~/kdesrc
./kdesrc-build qt-copy
</syntaxhighlight>

{{tip|If you have the [http://www.gnu.org/software/screen/ GNU screen] program available then you should definitely use it to run kdesrc-build, as you can detach your kdesrc-build session and logout while kdesrc-build is still running.}}

If the build failed (kdesrc-build will error out with a nice bright red error message) then there are several possibilities:

# You are missing a key piece of required software (such as a development library)
# The KDE SC code being compiled is broken in some fashion to where it won't build. This is commonly due to newly committed code that worked on the developer's machine, or occasionally on Mondays (when incompatible changes are permitted to kdelibs).
# kdesrc-build is not setup properly. You may be trying to install to a directory that you have no permissions to access for instance, or you may have specified a system qtdir that does not exist.
# The module may depend on a newer version of qt-copy or kdelibs (or other module). In this case you'll have to run kdesrc-build to update the out-of-date module first.

How do you find out what the error was? The output of the failing command will be in the log directory. By default, all log output is in the {{path|log}} subdirectory of the KDE SC source directory. The log directory is laid out like this: {{path|log/date-run/module/output-file.log}}. To simplify finding the appropriate file, there are a couple of symlinks created:

{{path|log/latest}} always has the debugging output for the last time kdesrc-build was run (--pretend doesn't count toward this)
{{path|log/latest/<module>/error.log}} has the debugging output for the command that caused a module build to fail.

For instance if qt-copy just failed to build you could read the output like this:

<syntaxhighlight lang="bash">
cd ~/kderc
kwrite log/latest/qt-copy/error.log
</syntaxhighlight>

Replace kwrite with your preferred editor. Hopefully the output can guide you to resolving the problem. For instance, if the failure is a cmake output saying you're missing a library, install that library and try again. ;) For link errors you can try running a --refresh-build on the module (or if that doesn't work, required libraries like qt-copy and kdelibs).

If you're stumped by the error you may want to wait a day and try updating again, and hope that the reason for the error has been fixed. You can also try mailing the [http://www.kde.org/mailinglists/ kde-devel] mailing list to see if others know about the problem or have had similar issues.

== Running KDE ==

Assuming you got enough of the modules to build and install to have a working KDE installation, you'll still need to setup your environment correctly to run it. kdesrc-build doesn't help you out here (yet), so you should follow the instructions [[Getting_Started/Using_an_IDE_with_KDE4|here]].

Make sure to use the same paths as the ones you defined in .kdesrc-buildrc: for the KDEDIRS and KDEDIR variable use the setting of the "prefix" option (in the global section). For the QTDIR variable use the setting of the "qtdir" option.

== Keeping KDE up to date ==

Keeping your KDE installation up to date is as simple as running kdesrc-build again. Every kdesrc-build has these phases:

# Update the source code for all modules being built.
# Build and then install all the modules.

Old build directories are not deleted by default, so the build after a small update will not normally take as long as the initial build of a module. This is called "incremental make". However it may be necessary at times to perform a full rebuild due to inconsistencies between the build directory configuation and changes to the source directory. You can use the --refresh-build option to force a full rebuild.

For more information on how to take advantage of kdesrc-build, see the [http://kdesrc-build.kde.org/documentation online documentation] for kdesrc-build, which describes all of the module options and command line options available for kdesrc-build and gives tips on how to perform various useful tasks.

If you have any questions that are not answered please feel free to add them under the Discussion entry for this page and hopefully someone will be able to get the answer.

= See also =
* To browse the KDE Subversion repository, use [http://websvn.kde.org/trunk/KDE WebSVN].
* To browse any of the various KDE projects using git, you can go to [http://projects.kde.org KDE Git Projects] or to [http://gitweb.kde.org KDE Git Web].
* The Nokia Qt toolkit used by KDE can be browsed at [http://qt.gitorious.org/qt Nokia's Qt version on gitorious].

[[Category:Build_KDE]]
[[Category:Tutorial]]

Getting Started/Build/kdesrc-build-config

2012-02-11T17:12:37Z

Tstaerk: moved Getting Started/Build/kdesrc-buildrc to Getting Started/Build/kdesrc-build-config: make it clear what this article is about. Make it visible that this article is not kdesrc-build.

== kdesvn-buildrc ==

=== Introduction ===

The [[Getting_Started/Build/kdesvn-build|kdesvn-build]] program, which is used to download, build, and install [http://www.kde.org/ KDE] from the [http://websvn.kde.org/ KDE source repository], uses a file called {{path|kdesvn-buildrc}} in order to control what is downloaded and built, what options are used, and where KDE is installed to.

This is a description of how to use {{path|kdesvn-buildrc}}.

=== Creating your configuration ===

The kdesvn-build download will include a file called {{path|kdesvn-buildrc-sample}}, which is a sample configuration file suitable for building the KDE Software Compilation (SC).

To create your configuration, it is recommended to use this file as a base since it includes the standard list of KDE modules to build, in the correct order. (You can, of course, add or remove most modules if you like).

You can use any standard text editor to edit this file, such as KWrite, nano, vi, etc.

==== Global configuration ====

Once you open the file, you will see that it starts with some comments (on lines beginning with #), and then the world "global". This starts the global configuration for the kdesvn-buildrc, which is used to specify options which are common to all of the modules.

Each option in the global section is specified in the following form:
:option-name value

Many options are already listed, with default values, and comments about the option on top. Some options have more than one sample value listed. In this situation, all but one of these will have comments. If you want to use a different sample option, simply uncomment the line by deleting the '#' at the beginning, and commenting or deleting the other lines with the same option name.

Here's a short listing of some of the important global options:

* source-dir: This option controls where kdesvn-build will download the sources to. In addition, most other directories that kdesvn-build uses will be subdirectories of this directory by default, so it is a kind of "kdesvn-build prefix". The default value is {{path|~/kdesvn}}, which downloads the source in a subdirectory under your home directory.
* build-dir: This controls where kdesvn-build actually builds the various modules. Normally it is the directory {{path|build}} under your source directory.
* kdedir: This controls where the KDE SC (and the various supporting modules such as kdesupport) get installed to. The default is {{path|~/kde}}, which installs to your home directory.

{{note|As you can see, there are three different major directories, source, build, and install. The build directory is used to keep the source directory clean and to hold intermediate files that don't get installed}}

{{tip|You can use ~/ in these options to represent your home directory}}

* qtdir: This controls where Qt 4 is assumed to be. If you use the qt-copy module, it also controls where qt-copy is installed to. Default is {{path|~/qt4}}, which installs qt-copy to your home directory.

{{tip|qt-copy is a module specifically for building Nokia's Qt toolkit. See [[#qt-copy]] below for information about what is special.}}

* cmake-options: This controls what [[Development/Tutorials/CMake#Command_Line_Variables|options]] are passed to CMake for ''every'' KDE module. For instance, if you want to enable full debugging information, you could set:
:cmake-options -DCMAKE_BUILD_TYPE=debugfull

* make-options: This is used to pass command line options to the make command, which is what actually performs the build. The most likely option is -jN, where N is the number of jobs to perform at once. If you have a system with more than one CPU, it is recommended to use N = number_of_CPUs + 1. For instance, -j3 on a dual core machine or -j5 on a quad-core. You can lower this number if your system is sluggish during the build, but raising it won't buy you much in build speed.

* make-install-prefix: This is used to allow a program to run make install on your behalf. Normally with would be the sudo program, which is used to perform actions with administrator permissions. You only need this for the following:
# You want to install KDE to the system and not your home directory.
# Some installed files require elevated permissions to work properly (this is true for kdebase, and some files in kdelibs).

If this ''is'' the case for you, you can use this option (either globally, or for each module) to run make install using sudo, or su, etc.

==== Module configuration ====

After the global options are all done, you'll see the line "end global", which lets kdesvn-build know that all of the global options have been read.

Next in the kdesvn-buildrc are the module options. First off, modules are listed in the file, in the order they are to be built and installed. Each module is listed in the following format:
:module ''module-name''
::module-options
:end module

The ''module-name'' is how kdesvn-build refers to the module. It should match the name of the module you are downloading from the source repository. Base KDE modules are listed [http://websvn.kde.org/trunk/KDE/ in WebSVN]. Other modules are also available [http://websvn.kde.org/trunk/ in WebSVN].

One exception is that modules downloaded from git can have any module name you'd like that isn't already used, as kdesvn-build determines their download location using a specific ''repository'' option.

For each module you can specify options, in the same fashion as for the global options. Most of the time, if you set an option for a module, it completely overrides the global option, if any.

However, the cmake-options for a module is added to the global cmake-options, instead of replacing it, which allows you to avoid having to give the same cmake-options for all of your modules.

{{tip|If you need to disable a global cmake-option, you can specify it again for the module you need to disable it for, and give it the opposite value. For instance, if you were using }}-DCMAKE_BUILD_TYPE=debugfull globally but wanted Release mode for kdebindings, you could set cmake-options -DCMAKE_BUILD_TYPE=Release for kdebindings.

{{tip|If you get the warning from kdesvn-build that a certain module is not listed in the kdesvn-buildrc, make sure that you've added it to the kdesvn-buildrc, even if you have no options for it. If it's already in the kdesvn-buildrc, make sure you spelled the module name right on the command line.}}

==== qt-copy ====

The qt-copy module is special in that it uses configure-options instead of cmake-options, and it never inherits compilation flags that are set globally, since Qt uses a different build system than KDE software does. The sample kdesvn-buildrc contains a useful set of default configure flags, but if you aren't using qt-copy, you can simply comment the entire qt-copy module out.

Since Nokia's Qt is developed using git instead of Subversion, you must specify the ''repository'' option for qt-copy to choose which version of Qt you will use:

{|
|+ Qt Variants
|-
! Edition to build !! Repository to use
|-
| Official Nokia Qt || git://gitorious.org/qt/qt.git
|-
| Slightly modified Qt with KDE-specific patches and bugfixes (recommended if you're going to the trouble anyways) || git://gitorious.org/+kde-developers/qt/kde-qt.git
|}

Either way you should specify a ''branch'' of ''master'' to choose the default version.

If you choose kde-qt make sure to look at the README.kde-qt after kdesvn-build downloads the module for you as well!

=== Location ===

kdesvn-build will search in several locations for your rc file.

# First, kdesvn-build will look for a file called {{path|kdesvn-buildrc}} in ''the current directory''. Notice that in this situation there is no leading dot on the filename. This allows you to control the build based on what directory you're in, which would be useful for maintaining two different Subversion installs.
# If no kdesvn-buildrc is found, kdesvn-build will look for a {{path|~/.kdesvn-buildrc}}. Notice there '''is''' a leading dot on the filename in this situation. This is the standard Linux/UNIX convention for configuration files stored in the home directory, and marks this as a hidden file. So if you try to find the file in Dolphin or Konqueror, you may need to Show Hidden Files first. This controls the default configuration kdesvn-build will use, no matter what directory you run kdesvn-build from.
# If you specify the --rc-file option to kdesvn-build, kdesvn-build will try to read the given kdesvn-buildrc file instead of the default ones. This is also independent of what directory kdesvn-build is run in. But, you must remember to pass this option every time, so it is only useful for testing or for a one-time-only run.

=== Making changes ===

When you make changes to values in your kdesvn-buildrc, they may not always be picked up immediately. For example, if you change cmake-options but kdesvn-build has no reason to run CMake again, then you'll still be building with your old cmake-options.

{{note|This is only partially true -- kdesvn-build will be able to note that some values have changed and automatically re-run affected build portions as appropriate, but this advice still applies until this feature has been integrated for all options}}

The safest way to ensure that a change to your module's options is picked up is to use the --refresh-build option when rebuilding a module. This option causes kdesvn-build to completely rebuild the given module, which includes running cmake and clearing out the build directory.

Using --refresh-build takes the most time. Often, it is enough to use --reconfigure instead of --refresh-build, which runs CMake but does not clear out the build directory. But if --reconfigure doesn't work you'll end up doing --refresh-build anyways.

On the other hand, if you change the svn-server option to move where kdesvn-build is downloading from, you need to run kdesvn-build one time with the --svn-only option, so that kdesvn-build can perform the correct "svn switch" command.

=== Conclusion ===

The kdesvn-buildrc file is one of the major reasons to use kdesvn-build instead of building manually, as it will allow you to specify build settings to use all of the time instead of having to always remember to type in the correct command line settings and export the right environment variables. There are many more options than the ones covered here, which are mostly [http://kdesvn-build.kde.org/documentation/ detailed at the kdesvn-build documentation]. However, these options are enough to get you a working KDE installation.

Getting Started/Build/kdesrc-buildrc

2012-02-11T17:12:37Z

Tstaerk: moved Getting Started/Build/kdesrc-buildrc to Getting Started/Build/kdesrc-build-config: make it clear what this article is about. Make it visible that this article is not kdesrc-build.

#REDIRECT [[Getting Started/Build/kdesrc-build-config]]

Getting Started/Build/kdesrc-build-config

2012-02-11T16:45:29Z

Tstaerk: /* Module configuration */

Getting Started/Build/kdesrc-build-config

2012-02-11T16:44:47Z

Tstaerk: /* Module configuration */

== kdesvn-buildrc ==

=== Introduction ===

The [[Getting_Started/Build/kdesvn-build|kdesvn-build]] program, which is used to download, build, and install [http://www.kde.org/ KDE] from the [http://websvn.kde.org/ KDE source repository], uses a file called {{path|kdesvn-buildrc}} in order to control what is downloaded and built, what options are used, and where KDE is installed to.

This is a description of how to use {{path|kdesvn-buildrc}}.

=== Creating your configuration ===

The kdesvn-build download will include a file called {{path|kdesvn-buildrc-sample}}, which is a sample configuration file suitable for building the KDE Software Compilation (SC).

To create your configuration, it is recommended to use this file as a base since it includes the standard list of KDE modules to build, in the correct order. (You can, of course, add or remove most modules if you like).

You can use any standard text editor to edit this file, such as KWrite, nano, vi, etc.

==== Global configuration ====

Once you open the file, you will see that it starts with some comments (on lines beginning with #), and then the world "global". This starts the global configuration for the kdesvn-buildrc, which is used to specify options which are common to all of the modules.

Each option in the global section is specified in the following form:
:option-name value

Many options are already listed, with default values, and comments about the option on top. Some options have more than one sample value listed. In this situation, all but one of these will have comments. If you want to use a different sample option, simply uncomment the line by deleting the '#' at the beginning, and commenting or deleting the other lines with the same option name.

Here's a short listing of some of the important global options:

* source-dir: This option controls where kdesvn-build will download the sources to. In addition, most other directories that kdesvn-build uses will be subdirectories of this directory by default, so it is a kind of "kdesvn-build prefix". The default value is {{path|~/kdesvn}}, which downloads the source in a subdirectory under your home directory.
* build-dir: This controls where kdesvn-build actually builds the various modules. Normally it is the directory {{path|build}} under your source directory.
* kdedir: This controls where the KDE SC (and the various supporting modules such as kdesupport) get installed to. The default is {{path|~/kde}}, which installs to your home directory.

{{note|As you can see, there are three different major directories, source, build, and install. The build directory is used to keep the source directory clean and to hold intermediate files that don't get installed}}

{{tip|You can use ~/ in these options to represent your home directory}}

* qtdir: This controls where Qt 4 is assumed to be. If you use the qt-copy module, it also controls where qt-copy is installed to. Default is {{path|~/qt4}}, which installs qt-copy to your home directory.

{{tip|qt-copy is a module specifically for building Nokia's Qt toolkit. See [[#qt-copy]] below for information about what is special.}}

* cmake-options: This controls what [[Development/Tutorials/CMake#Command_Line_Variables|options]] are passed to CMake for ''every'' KDE module. For instance, if you want to enable full debugging information, you could set:
:cmake-options -DCMAKE_BUILD_TYPE=debugfull

* make-options: This is used to pass command line options to the make command, which is what actually performs the build. The most likely option is -jN, where N is the number of jobs to perform at once. If you have a system with more than one CPU, it is recommended to use N = number_of_CPUs + 1. For instance, -j3 on a dual core machine or -j5 on a quad-core. You can lower this number if your system is sluggish during the build, but raising it won't buy you much in build speed.

* make-install-prefix: This is used to allow a program to run make install on your behalf. Normally with would be the sudo program, which is used to perform actions with administrator permissions. You only need this for the following:
# You want to install KDE to the system and not your home directory.
# Some installed files require elevated permissions to work properly (this is true for kdebase, and some files in kdelibs).

If this ''is'' the case for you, you can use this option (either globally, or for each module) to run make install using sudo, or su, etc.

==== Module configuration ====

After the global options are all done, you'll see the line "end global", which lets kdesvn-build know that all of the global options have been read.

Next in the kdesvn-buildrc are the module options. First off, modules are listed in the file, in the order they are to be built and installed. Each module is listed in the following format:
:module ''module-name''
::module-options
:end module

The ''module-name'' is how kdesvn-build refers to the module. It should match the name of the module you are downloading from the source repository. Base KDE modules are listed [http://websvn.kde.org/trunk/KDE/ in WebSVN]. Other modules are also available [http://websvn.kde.org/trunk/ in WebSVN].

One exception is that modules downloaded from git can have any module name you'd like that isn't already used, as kdesvn-build determines their download location using a specific ''repository'' option.

For each module you can specify options, in the same fashion as for the global options. Most of the time, if you set an option for a module, it completely overrides the global option, if any.

However, the cmake-options for a module is added to the global cmake-options, instead of replacing it, which allows you to avoid having to give the same cmake-options for all of your modules.

{{tip|If you need to disable a global cmake-option, you can specify it again for the module you need to disable it for, and give it the opposite value. For instance, if you were using -DCMAKE_BUILD_TYPE=debugfull}} globally but wanted Release mode for kdebindings, you could set cmake-options -DCMAKE_BUILD_TYPE=Release for kdebindings.

{{tip|If you get the warning from kdesvn-build that a certain module is not listed in the kdesvn-buildrc, make sure that you've added it to the kdesvn-buildrc, even if you have no options for it. If it's already in the kdesvn-buildrc, make sure you spelled the module name right on the command line.}}

==== qt-copy ====

The qt-copy module is special in that it uses configure-options instead of cmake-options, and it never inherits compilation flags that are set globally, since Qt uses a different build system than KDE software does. The sample kdesvn-buildrc contains a useful set of default configure flags, but if you aren't using qt-copy, you can simply comment the entire qt-copy module out.

Since Nokia's Qt is developed using git instead of Subversion, you must specify the ''repository'' option for qt-copy to choose which version of Qt you will use:

{|
|+ Qt Variants
|-
! Edition to build !! Repository to use
|-
| Official Nokia Qt || git://gitorious.org/qt/qt.git
|-
| Slightly modified Qt with KDE-specific patches and bugfixes (recommended if you're going to the trouble anyways) || git://gitorious.org/+kde-developers/qt/kde-qt.git
|}

Either way you should specify a ''branch'' of ''master'' to choose the default version.

If you choose kde-qt make sure to look at the README.kde-qt after kdesvn-build downloads the module for you as well!

=== Location ===

kdesvn-build will search in several locations for your rc file.

# First, kdesvn-build will look for a file called {{path|kdesvn-buildrc}} in ''the current directory''. Notice that in this situation there is no leading dot on the filename. This allows you to control the build based on what directory you're in, which would be useful for maintaining two different Subversion installs.
# If no kdesvn-buildrc is found, kdesvn-build will look for a {{path|~/.kdesvn-buildrc}}. Notice there '''is''' a leading dot on the filename in this situation. This is the standard Linux/UNIX convention for configuration files stored in the home directory, and marks this as a hidden file. So if you try to find the file in Dolphin or Konqueror, you may need to Show Hidden Files first. This controls the default configuration kdesvn-build will use, no matter what directory you run kdesvn-build from.
# If you specify the --rc-file option to kdesvn-build, kdesvn-build will try to read the given kdesvn-buildrc file instead of the default ones. This is also independent of what directory kdesvn-build is run in. But, you must remember to pass this option every time, so it is only useful for testing or for a one-time-only run.

=== Making changes ===

When you make changes to values in your kdesvn-buildrc, they may not always be picked up immediately. For example, if you change cmake-options but kdesvn-build has no reason to run CMake again, then you'll still be building with your old cmake-options.

{{note|This is only partially true -- kdesvn-build will be able to note that some values have changed and automatically re-run affected build portions as appropriate, but this advice still applies until this feature has been integrated for all options}}

The safest way to ensure that a change to your module's options is picked up is to use the --refresh-build option when rebuilding a module. This option causes kdesvn-build to completely rebuild the given module, which includes running cmake and clearing out the build directory.

Using --refresh-build takes the most time. Often, it is enough to use --reconfigure instead of --refresh-build, which runs CMake but does not clear out the build directory. But if --reconfigure doesn't work you'll end up doing --refresh-build anyways.

On the other hand, if you change the svn-server option to move where kdesvn-build is downloading from, you need to run kdesvn-build one time with the --svn-only option, so that kdesvn-build can perform the correct "svn switch" command.

=== Conclusion ===

The kdesvn-buildrc file is one of the major reasons to use kdesvn-build instead of building manually, as it will allow you to specify build settings to use all of the time instead of having to always remember to type in the correct command line settings and export the right environment variables. There are many more options than the ones covered here, which are mostly [http://kdesvn-build.kde.org/documentation/ detailed at the kdesvn-build documentation]. However, these options are enough to get you a working KDE installation.

Getting Started/Build/kdesrc-build-config

2012-02-11T16:43:39Z

Tstaerk: /* Module configuration */

== kdesvn-buildrc ==

=== Introduction ===

The [[Getting_Started/Build/kdesvn-build|kdesvn-build]] program, which is used to download, build, and install [http://www.kde.org/ KDE] from the [http://websvn.kde.org/ KDE source repository], uses a file called {{path|kdesvn-buildrc}} in order to control what is downloaded and built, what options are used, and where KDE is installed to.

This is a description of how to use {{path|kdesvn-buildrc}}.

=== Creating your configuration ===

The kdesvn-build download will include a file called {{path|kdesvn-buildrc-sample}}, which is a sample configuration file suitable for building the KDE Software Compilation (SC).

To create your configuration, it is recommended to use this file as a base since it includes the standard list of KDE modules to build, in the correct order. (You can, of course, add or remove most modules if you like).

You can use any standard text editor to edit this file, such as KWrite, nano, vi, etc.

==== Global configuration ====

Once you open the file, you will see that it starts with some comments (on lines beginning with #), and then the world "global". This starts the global configuration for the kdesvn-buildrc, which is used to specify options which are common to all of the modules.

Each option in the global section is specified in the following form:
:option-name value

Many options are already listed, with default values, and comments about the option on top. Some options have more than one sample value listed. In this situation, all but one of these will have comments. If you want to use a different sample option, simply uncomment the line by deleting the '#' at the beginning, and commenting or deleting the other lines with the same option name.

Here's a short listing of some of the important global options:

* source-dir: This option controls where kdesvn-build will download the sources to. In addition, most other directories that kdesvn-build uses will be subdirectories of this directory by default, so it is a kind of "kdesvn-build prefix". The default value is {{path|~/kdesvn}}, which downloads the source in a subdirectory under your home directory.
* build-dir: This controls where kdesvn-build actually builds the various modules. Normally it is the directory {{path|build}} under your source directory.
* kdedir: This controls where the KDE SC (and the various supporting modules such as kdesupport) get installed to. The default is {{path|~/kde}}, which installs to your home directory.

{{note|As you can see, there are three different major directories, source, build, and install. The build directory is used to keep the source directory clean and to hold intermediate files that don't get installed}}

{{tip|You can use ~/ in these options to represent your home directory}}

* qtdir: This controls where Qt 4 is assumed to be. If you use the qt-copy module, it also controls where qt-copy is installed to. Default is {{path|~/qt4}}, which installs qt-copy to your home directory.

{{tip|qt-copy is a module specifically for building Nokia's Qt toolkit. See [[#qt-copy]] below for information about what is special.}}

* cmake-options: This controls what [[Development/Tutorials/CMake#Command_Line_Variables|options]] are passed to CMake for ''every'' KDE module. For instance, if you want to enable full debugging information, you could set:
:cmake-options -DCMAKE_BUILD_TYPE=debugfull

* make-options: This is used to pass command line options to the make command, which is what actually performs the build. The most likely option is -jN, where N is the number of jobs to perform at once. If you have a system with more than one CPU, it is recommended to use N = number_of_CPUs + 1. For instance, -j3 on a dual core machine or -j5 on a quad-core. You can lower this number if your system is sluggish during the build, but raising it won't buy you much in build speed.

* make-install-prefix: This is used to allow a program to run make install on your behalf. Normally with would be the sudo program, which is used to perform actions with administrator permissions. You only need this for the following:
# You want to install KDE to the system and not your home directory.
# Some installed files require elevated permissions to work properly (this is true for kdebase, and some files in kdelibs).

If this ''is'' the case for you, you can use this option (either globally, or for each module) to run make install using sudo, or su, etc.

==== Module configuration ====

After the global options are all done, you'll see the line "end global", which lets kdesvn-build know that all of the global options have been read.

Next in the kdesvn-buildrc are the module options. First off, modules are listed in the file, in the order they are to be built and installed. Each module is listed in the following format:
:module ''module-name''
::module-options
:end module

The ''module-name'' is how kdesvn-build refers to the module. It should match the name of the module you are downloading from the source repository. Base KDE modules are listed [http://websvn.kde.org/trunk/KDE/ in WebSVN]. Other modules are also available [http://websvn.kde.org/trunk/ in WebSVN].

One exception is that modules downloaded from git can have any module name you'd like that isn't already used, as kdesvn-build determines their download location using a specific ''repository'' option.

For each module you can specify options, in the same fashion as for the global options. Most of the time, if you set an option for a module, it completely overrides the global option, if any.

However, the cmake-options for a module is added to the global cmake-options, instead of replacing it, which allows you to avoid having to give the same cmake-options for all of your modules.

{{tip|If you need to disable a global cmake-option, you can specify it again for the module you need to disable it for, and give it the opposite value. For instance, if you were using
CMAKE_BUILD_TYPE=debugfull}} globally but wanted Release mode for kdebindings, you could set cmake-options -DCMAKE_BUILD_TYPE=Release for kdebindings.

{{tip|If you get the warning from kdesvn-build that a certain module is not listed in the kdesvn-buildrc, make sure that you've added it to the kdesvn-buildrc, even if you have no options for it. If it's already in the kdesvn-buildrc, make sure you spelled the module name right on the command line.}}

==== qt-copy ====

The qt-copy module is special in that it uses configure-options instead of cmake-options, and it never inherits compilation flags that are set globally, since Qt uses a different build system than KDE software does. The sample kdesvn-buildrc contains a useful set of default configure flags, but if you aren't using qt-copy, you can simply comment the entire qt-copy module out.

Since Nokia's Qt is developed using git instead of Subversion, you must specify the ''repository'' option for qt-copy to choose which version of Qt you will use:

{|
|+ Qt Variants
|-
! Edition to build !! Repository to use
|-
| Official Nokia Qt || git://gitorious.org/qt/qt.git
|-
| Slightly modified Qt with KDE-specific patches and bugfixes (recommended if you're going to the trouble anyways) || git://gitorious.org/+kde-developers/qt/kde-qt.git
|}

Either way you should specify a ''branch'' of ''master'' to choose the default version.

If you choose kde-qt make sure to look at the README.kde-qt after kdesvn-build downloads the module for you as well!

=== Location ===

kdesvn-build will search in several locations for your rc file.

# First, kdesvn-build will look for a file called {{path|kdesvn-buildrc}} in ''the current directory''. Notice that in this situation there is no leading dot on the filename. This allows you to control the build based on what directory you're in, which would be useful for maintaining two different Subversion installs.
# If no kdesvn-buildrc is found, kdesvn-build will look for a {{path|~/.kdesvn-buildrc}}. Notice there '''is''' a leading dot on the filename in this situation. This is the standard Linux/UNIX convention for configuration files stored in the home directory, and marks this as a hidden file. So if you try to find the file in Dolphin or Konqueror, you may need to Show Hidden Files first. This controls the default configuration kdesvn-build will use, no matter what directory you run kdesvn-build from.
# If you specify the --rc-file option to kdesvn-build, kdesvn-build will try to read the given kdesvn-buildrc file instead of the default ones. This is also independent of what directory kdesvn-build is run in. But, you must remember to pass this option every time, so it is only useful for testing or for a one-time-only run.

=== Making changes ===

When you make changes to values in your kdesvn-buildrc, they may not always be picked up immediately. For example, if you change cmake-options but kdesvn-build has no reason to run CMake again, then you'll still be building with your old cmake-options.

{{note|This is only partially true -- kdesvn-build will be able to note that some values have changed and automatically re-run affected build portions as appropriate, but this advice still applies until this feature has been integrated for all options}}

The safest way to ensure that a change to your module's options is picked up is to use the --refresh-build option when rebuilding a module. This option causes kdesvn-build to completely rebuild the given module, which includes running cmake and clearing out the build directory.

Using --refresh-build takes the most time. Often, it is enough to use --reconfigure instead of --refresh-build, which runs CMake but does not clear out the build directory. But if --reconfigure doesn't work you'll end up doing --refresh-build anyways.

On the other hand, if you change the svn-server option to move where kdesvn-build is downloading from, you need to run kdesvn-build one time with the --svn-only option, so that kdesvn-build can perform the correct "svn switch" command.

=== Conclusion ===

The kdesvn-buildrc file is one of the major reasons to use kdesvn-build instead of building manually, as it will allow you to specify build settings to use all of the time instead of having to always remember to type in the correct command line settings and export the right environment variables. There are many more options than the ones covered here, which are mostly [http://kdesvn-build.kde.org/documentation/ detailed at the kdesvn-build documentation]. However, these options are enough to get you a working KDE installation.

Getting Started/Build/kdesrc-build-config

2012-02-11T16:42:46Z

Tstaerk: /* Module configuration */

== kdesvn-buildrc ==

=== Introduction ===

The [[Getting_Started/Build/kdesvn-build|kdesvn-build]] program, which is used to download, build, and install [http://www.kde.org/ KDE] from the [http://websvn.kde.org/ KDE source repository], uses a file called {{path|kdesvn-buildrc}} in order to control what is downloaded and built, what options are used, and where KDE is installed to.

This is a description of how to use {{path|kdesvn-buildrc}}.

=== Creating your configuration ===

The kdesvn-build download will include a file called {{path|kdesvn-buildrc-sample}}, which is a sample configuration file suitable for building the KDE Software Compilation (SC).

To create your configuration, it is recommended to use this file as a base since it includes the standard list of KDE modules to build, in the correct order. (You can, of course, add or remove most modules if you like).

You can use any standard text editor to edit this file, such as KWrite, nano, vi, etc.

==== Global configuration ====

Once you open the file, you will see that it starts with some comments (on lines beginning with #), and then the world "global". This starts the global configuration for the kdesvn-buildrc, which is used to specify options which are common to all of the modules.

Each option in the global section is specified in the following form:
:option-name value

Many options are already listed, with default values, and comments about the option on top. Some options have more than one sample value listed. In this situation, all but one of these will have comments. If you want to use a different sample option, simply uncomment the line by deleting the '#' at the beginning, and commenting or deleting the other lines with the same option name.

Here's a short listing of some of the important global options:

* source-dir: This option controls where kdesvn-build will download the sources to. In addition, most other directories that kdesvn-build uses will be subdirectories of this directory by default, so it is a kind of "kdesvn-build prefix". The default value is {{path|~/kdesvn}}, which downloads the source in a subdirectory under your home directory.
* build-dir: This controls where kdesvn-build actually builds the various modules. Normally it is the directory {{path|build}} under your source directory.
* kdedir: This controls where the KDE SC (and the various supporting modules such as kdesupport) get installed to. The default is {{path|~/kde}}, which installs to your home directory.

{{note|As you can see, there are three different major directories, source, build, and install. The build directory is used to keep the source directory clean and to hold intermediate files that don't get installed}}

{{tip|You can use ~/ in these options to represent your home directory}}

* qtdir: This controls where Qt 4 is assumed to be. If you use the qt-copy module, it also controls where qt-copy is installed to. Default is {{path|~/qt4}}, which installs qt-copy to your home directory.

{{tip|qt-copy is a module specifically for building Nokia's Qt toolkit. See [[#qt-copy]] below for information about what is special.}}

* cmake-options: This controls what [[Development/Tutorials/CMake#Command_Line_Variables|options]] are passed to CMake for ''every'' KDE module. For instance, if you want to enable full debugging information, you could set:
:cmake-options -DCMAKE_BUILD_TYPE=debugfull

* make-options: This is used to pass command line options to the make command, which is what actually performs the build. The most likely option is -jN, where N is the number of jobs to perform at once. If you have a system with more than one CPU, it is recommended to use N = number_of_CPUs + 1. For instance, -j3 on a dual core machine or -j5 on a quad-core. You can lower this number if your system is sluggish during the build, but raising it won't buy you much in build speed.

* make-install-prefix: This is used to allow a program to run make install on your behalf. Normally with would be the sudo program, which is used to perform actions with administrator permissions. You only need this for the following:
# You want to install KDE to the system and not your home directory.
# Some installed files require elevated permissions to work properly (this is true for kdebase, and some files in kdelibs).

If this ''is'' the case for you, you can use this option (either globally, or for each module) to run make install using sudo, or su, etc.

==== Module configuration ====

After the global options are all done, you'll see the line "end global", which lets kdesvn-build know that all of the global options have been read.

Next in the kdesvn-buildrc are the module options. First off, modules are listed in the file, in the order they are to be built and installed. Each module is listed in the following format:
:module ''module-name''
::module-options
:end module

The ''module-name'' is how kdesvn-build refers to the module. It should match the name of the module you are downloading from the source repository. Base KDE modules are listed [http://websvn.kde.org/trunk/KDE/ in WebSVN]. Other modules are also available [http://websvn.kde.org/trunk/ in WebSVN].

One exception is that modules downloaded from git can have any module name you'd like that isn't already used, as kdesvn-build determines their download location using a specific ''repository'' option.

For each module you can specify options, in the same fashion as for the global options. Most of the time, if you set an option for a module, it completely overrides the global option, if any.

However, the cmake-options for a module is added to the global cmake-options, instead of replacing it, which allows you to avoid having to give the same cmake-options for all of your modules.

{{tip|If you need to disable a global cmake-option, you can specify it again for the module you need to disable it for, and give it the opposite value. For instance, if you were using CMAKE_BUILD_TYPE=debugfull}} globally but wanted Release mode for kdebindings, you could set cmake-options -DCMAKE_BUILD_TYPE=Release for kdebindings.

{{tip|If you get the warning from kdesvn-build that a certain module is not listed in the kdesvn-buildrc, make sure that you've added it to the kdesvn-buildrc, even if you have no options for it. If it's already in the kdesvn-buildrc, make sure you spelled the module name right on the command line.}}

==== qt-copy ====

The qt-copy module is special in that it uses configure-options instead of cmake-options, and it never inherits compilation flags that are set globally, since Qt uses a different build system than KDE software does. The sample kdesvn-buildrc contains a useful set of default configure flags, but if you aren't using qt-copy, you can simply comment the entire qt-copy module out.

Since Nokia's Qt is developed using git instead of Subversion, you must specify the ''repository'' option for qt-copy to choose which version of Qt you will use:

{|
|+ Qt Variants
|-
! Edition to build !! Repository to use
|-
| Official Nokia Qt || git://gitorious.org/qt/qt.git
|-
| Slightly modified Qt with KDE-specific patches and bugfixes (recommended if you're going to the trouble anyways) || git://gitorious.org/+kde-developers/qt/kde-qt.git
|}

Either way you should specify a ''branch'' of ''master'' to choose the default version.

If you choose kde-qt make sure to look at the README.kde-qt after kdesvn-build downloads the module for you as well!

=== Location ===

kdesvn-build will search in several locations for your rc file.

# First, kdesvn-build will look for a file called {{path|kdesvn-buildrc}} in ''the current directory''. Notice that in this situation there is no leading dot on the filename. This allows you to control the build based on what directory you're in, which would be useful for maintaining two different Subversion installs.
# If no kdesvn-buildrc is found, kdesvn-build will look for a {{path|~/.kdesvn-buildrc}}. Notice there '''is''' a leading dot on the filename in this situation. This is the standard Linux/UNIX convention for configuration files stored in the home directory, and marks this as a hidden file. So if you try to find the file in Dolphin or Konqueror, you may need to Show Hidden Files first. This controls the default configuration kdesvn-build will use, no matter what directory you run kdesvn-build from.
# If you specify the --rc-file option to kdesvn-build, kdesvn-build will try to read the given kdesvn-buildrc file instead of the default ones. This is also independent of what directory kdesvn-build is run in. But, you must remember to pass this option every time, so it is only useful for testing or for a one-time-only run.

=== Making changes ===

When you make changes to values in your kdesvn-buildrc, they may not always be picked up immediately. For example, if you change cmake-options but kdesvn-build has no reason to run CMake again, then you'll still be building with your old cmake-options.

{{note|This is only partially true -- kdesvn-build will be able to note that some values have changed and automatically re-run affected build portions as appropriate, but this advice still applies until this feature has been integrated for all options}}

The safest way to ensure that a change to your module's options is picked up is to use the --refresh-build option when rebuilding a module. This option causes kdesvn-build to completely rebuild the given module, which includes running cmake and clearing out the build directory.

Using --refresh-build takes the most time. Often, it is enough to use --reconfigure instead of --refresh-build, which runs CMake but does not clear out the build directory. But if --reconfigure doesn't work you'll end up doing --refresh-build anyways.

On the other hand, if you change the svn-server option to move where kdesvn-build is downloading from, you need to run kdesvn-build one time with the --svn-only option, so that kdesvn-build can perform the correct "svn switch" command.

=== Conclusion ===

The kdesvn-buildrc file is one of the major reasons to use kdesvn-build instead of building manually, as it will allow you to specify build settings to use all of the time instead of having to always remember to type in the correct command line settings and export the right environment variables. There are many more options than the ones covered here, which are mostly [http://kdesvn-build.kde.org/documentation/ detailed at the kdesvn-build documentation]. However, these options are enough to get you a working KDE installation.

Getting Started/Build/kdesrc-build-config

2012-02-11T16:41:32Z

Tstaerk: /* Module configuration */

== kdesvn-buildrc ==

=== Introduction ===

The [[Getting_Started/Build/kdesvn-build|kdesvn-build]] program, which is used to download, build, and install [http://www.kde.org/ KDE] from the [http://websvn.kde.org/ KDE source repository], uses a file called {{path|kdesvn-buildrc}} in order to control what is downloaded and built, what options are used, and where KDE is installed to.

This is a description of how to use {{path|kdesvn-buildrc}}.

=== Creating your configuration ===

The kdesvn-build download will include a file called {{path|kdesvn-buildrc-sample}}, which is a sample configuration file suitable for building the KDE Software Compilation (SC).

To create your configuration, it is recommended to use this file as a base since it includes the standard list of KDE modules to build, in the correct order. (You can, of course, add or remove most modules if you like).

You can use any standard text editor to edit this file, such as KWrite, nano, vi, etc.

==== Global configuration ====

Once you open the file, you will see that it starts with some comments (on lines beginning with #), and then the world "global". This starts the global configuration for the kdesvn-buildrc, which is used to specify options which are common to all of the modules.

Each option in the global section is specified in the following form:
:option-name value

Many options are already listed, with default values, and comments about the option on top. Some options have more than one sample value listed. In this situation, all but one of these will have comments. If you want to use a different sample option, simply uncomment the line by deleting the '#' at the beginning, and commenting or deleting the other lines with the same option name.

Here's a short listing of some of the important global options:

* source-dir: This option controls where kdesvn-build will download the sources to. In addition, most other directories that kdesvn-build uses will be subdirectories of this directory by default, so it is a kind of "kdesvn-build prefix". The default value is {{path|~/kdesvn}}, which downloads the source in a subdirectory under your home directory.
* build-dir: This controls where kdesvn-build actually builds the various modules. Normally it is the directory {{path|build}} under your source directory.
* kdedir: This controls where the KDE SC (and the various supporting modules such as kdesupport) get installed to. The default is {{path|~/kde}}, which installs to your home directory.

{{note|As you can see, there are three different major directories, source, build, and install. The build directory is used to keep the source directory clean and to hold intermediate files that don't get installed}}

{{tip|You can use ~/ in these options to represent your home directory}}

* qtdir: This controls where Qt 4 is assumed to be. If you use the qt-copy module, it also controls where qt-copy is installed to. Default is {{path|~/qt4}}, which installs qt-copy to your home directory.

{{tip|qt-copy is a module specifically for building Nokia's Qt toolkit. See [[#qt-copy]] below for information about what is special.}}

* cmake-options: This controls what [[Development/Tutorials/CMake#Command_Line_Variables|options]] are passed to CMake for ''every'' KDE module. For instance, if you want to enable full debugging information, you could set:
:cmake-options -DCMAKE_BUILD_TYPE=debugfull

* make-options: This is used to pass command line options to the make command, which is what actually performs the build. The most likely option is -jN, where N is the number of jobs to perform at once. If you have a system with more than one CPU, it is recommended to use N = number_of_CPUs + 1. For instance, -j3 on a dual core machine or -j5 on a quad-core. You can lower this number if your system is sluggish during the build, but raising it won't buy you much in build speed.

* make-install-prefix: This is used to allow a program to run make install on your behalf. Normally with would be the sudo program, which is used to perform actions with administrator permissions. You only need this for the following:
# You want to install KDE to the system and not your home directory.
# Some installed files require elevated permissions to work properly (this is true for kdebase, and some files in kdelibs).

If this ''is'' the case for you, you can use this option (either globally, or for each module) to run make install using sudo, or su, etc.

==== Module configuration ====

After the global options are all done, you'll see the line "end global", which lets kdesvn-build know that all of the global options have been read.

Next in the kdesvn-buildrc are the module options. First off, modules are listed in the file, in the order they are to be built and installed. Each module is listed in the following format:
:module ''module-name''
::module-options
:end module

The ''module-name'' is how kdesvn-build refers to the module. It should match the name of the module you are downloading from the source repository. Base KDE modules are listed [http://websvn.kde.org/trunk/KDE/ in WebSVN]. Other modules are also available [http://websvn.kde.org/trunk/ in WebSVN].

One exception is that modules downloaded from git can have any module name you'd like that isn't already used, as kdesvn-build determines their download location using a specific ''repository'' option.

For each module you can specify options, in the same fashion as for the global options. Most of the time, if you set an option for a module, it completely overrides the global option, if any.

However, the cmake-options for a module is added to the global cmake-options, instead of replacing it, which allows you to avoid having to give the same cmake-options for all of your modules.

{{tip|If you need to disable a global cmake-option, you can specify it again for the module you need to disable it for, and give it the opposite value. For instance, if you were using}} CMAKE_BUILD_TYPE=debugfull globally but wanted Release mode for kdebindings, you could set cmake-options -DCMAKE_BUILD_TYPE=Release for kdebindings.

{{tip|If you get the warning from kdesvn-build that a certain module is not listed in the kdesvn-buildrc, make sure that you've added it to the kdesvn-buildrc, even if you have no options for it. If it's already in the kdesvn-buildrc, make sure you spelled the module name right on the command line.}}

==== qt-copy ====

The qt-copy module is special in that it uses configure-options instead of cmake-options, and it never inherits compilation flags that are set globally, since Qt uses a different build system than KDE software does. The sample kdesvn-buildrc contains a useful set of default configure flags, but if you aren't using qt-copy, you can simply comment the entire qt-copy module out.

Since Nokia's Qt is developed using git instead of Subversion, you must specify the ''repository'' option for qt-copy to choose which version of Qt you will use:

{|
|+ Qt Variants
|-
! Edition to build !! Repository to use
|-
| Official Nokia Qt || git://gitorious.org/qt/qt.git
|-
| Slightly modified Qt with KDE-specific patches and bugfixes (recommended if you're going to the trouble anyways) || git://gitorious.org/+kde-developers/qt/kde-qt.git
|}

Either way you should specify a ''branch'' of ''master'' to choose the default version.

If you choose kde-qt make sure to look at the README.kde-qt after kdesvn-build downloads the module for you as well!

=== Location ===

kdesvn-build will search in several locations for your rc file.

# First, kdesvn-build will look for a file called {{path|kdesvn-buildrc}} in ''the current directory''. Notice that in this situation there is no leading dot on the filename. This allows you to control the build based on what directory you're in, which would be useful for maintaining two different Subversion installs.
# If no kdesvn-buildrc is found, kdesvn-build will look for a {{path|~/.kdesvn-buildrc}}. Notice there '''is''' a leading dot on the filename in this situation. This is the standard Linux/UNIX convention for configuration files stored in the home directory, and marks this as a hidden file. So if you try to find the file in Dolphin or Konqueror, you may need to Show Hidden Files first. This controls the default configuration kdesvn-build will use, no matter what directory you run kdesvn-build from.
# If you specify the --rc-file option to kdesvn-build, kdesvn-build will try to read the given kdesvn-buildrc file instead of the default ones. This is also independent of what directory kdesvn-build is run in. But, you must remember to pass this option every time, so it is only useful for testing or for a one-time-only run.

=== Making changes ===

When you make changes to values in your kdesvn-buildrc, they may not always be picked up immediately. For example, if you change cmake-options but kdesvn-build has no reason to run CMake again, then you'll still be building with your old cmake-options.

{{note|This is only partially true -- kdesvn-build will be able to note that some values have changed and automatically re-run affected build portions as appropriate, but this advice still applies until this feature has been integrated for all options}}

The safest way to ensure that a change to your module's options is picked up is to use the --refresh-build option when rebuilding a module. This option causes kdesvn-build to completely rebuild the given module, which includes running cmake and clearing out the build directory.

Using --refresh-build takes the most time. Often, it is enough to use --reconfigure instead of --refresh-build, which runs CMake but does not clear out the build directory. But if --reconfigure doesn't work you'll end up doing --refresh-build anyways.

On the other hand, if you change the svn-server option to move where kdesvn-build is downloading from, you need to run kdesvn-build one time with the --svn-only option, so that kdesvn-build can perform the correct "svn switch" command.

=== Conclusion ===

The kdesvn-buildrc file is one of the major reasons to use kdesvn-build instead of building manually, as it will allow you to specify build settings to use all of the time instead of having to always remember to type in the correct command line settings and export the right environment variables. There are many more options than the ones covered here, which are mostly [http://kdesvn-build.kde.org/documentation/ detailed at the kdesvn-build documentation]. However, these options are enough to get you a working KDE installation.

Getting Started/Build/kdesrc-build-config

2012-02-11T16:40:41Z

Tstaerk: /* Module configuration */

== kdesvn-buildrc ==

=== Introduction ===

The [[Getting_Started/Build/kdesvn-build|kdesvn-build]] program, which is used to download, build, and install [http://www.kde.org/ KDE] from the [http://websvn.kde.org/ KDE source repository], uses a file called {{path|kdesvn-buildrc}} in order to control what is downloaded and built, what options are used, and where KDE is installed to.

This is a description of how to use {{path|kdesvn-buildrc}}.

=== Creating your configuration ===

The kdesvn-build download will include a file called {{path|kdesvn-buildrc-sample}}, which is a sample configuration file suitable for building the KDE Software Compilation (SC).

To create your configuration, it is recommended to use this file as a base since it includes the standard list of KDE modules to build, in the correct order. (You can, of course, add or remove most modules if you like).

You can use any standard text editor to edit this file, such as KWrite, nano, vi, etc.

==== Global configuration ====

Once you open the file, you will see that it starts with some comments (on lines beginning with #), and then the world "global". This starts the global configuration for the kdesvn-buildrc, which is used to specify options which are common to all of the modules.

Each option in the global section is specified in the following form:
:option-name value

Many options are already listed, with default values, and comments about the option on top. Some options have more than one sample value listed. In this situation, all but one of these will have comments. If you want to use a different sample option, simply uncomment the line by deleting the '#' at the beginning, and commenting or deleting the other lines with the same option name.

Here's a short listing of some of the important global options:

* source-dir: This option controls where kdesvn-build will download the sources to. In addition, most other directories that kdesvn-build uses will be subdirectories of this directory by default, so it is a kind of "kdesvn-build prefix". The default value is {{path|~/kdesvn}}, which downloads the source in a subdirectory under your home directory.
* build-dir: This controls where kdesvn-build actually builds the various modules. Normally it is the directory {{path|build}} under your source directory.
* kdedir: This controls where the KDE SC (and the various supporting modules such as kdesupport) get installed to. The default is {{path|~/kde}}, which installs to your home directory.

{{note|As you can see, there are three different major directories, source, build, and install. The build directory is used to keep the source directory clean and to hold intermediate files that don't get installed}}

{{tip|You can use ~/ in these options to represent your home directory}}

* qtdir: This controls where Qt 4 is assumed to be. If you use the qt-copy module, it also controls where qt-copy is installed to. Default is {{path|~/qt4}}, which installs qt-copy to your home directory.

{{tip|qt-copy is a module specifically for building Nokia's Qt toolkit. See [[#qt-copy]] below for information about what is special.}}

* cmake-options: This controls what [[Development/Tutorials/CMake#Command_Line_Variables|options]] are passed to CMake for ''every'' KDE module. For instance, if you want to enable full debugging information, you could set:
:cmake-options -DCMAKE_BUILD_TYPE=debugfull

* make-options: This is used to pass command line options to the make command, which is what actually performs the build. The most likely option is -jN, where N is the number of jobs to perform at once. If you have a system with more than one CPU, it is recommended to use N = number_of_CPUs + 1. For instance, -j3 on a dual core machine or -j5 on a quad-core. You can lower this number if your system is sluggish during the build, but raising it won't buy you much in build speed.

* make-install-prefix: This is used to allow a program to run make install on your behalf. Normally with would be the sudo program, which is used to perform actions with administrator permissions. You only need this for the following:
# You want to install KDE to the system and not your home directory.
# Some installed files require elevated permissions to work properly (this is true for kdebase, and some files in kdelibs).

If this ''is'' the case for you, you can use this option (either globally, or for each module) to run make install using sudo, or su, etc.

==== Module configuration ====

After the global options are all done, you'll see the line "end global", which lets kdesvn-build know that all of the global options have been read.

Next in the kdesvn-buildrc are the module options. First off, modules are listed in the file, in the order they are to be built and installed. Each module is listed in the following format:
:module ''module-name''
::module-options
:end module

The ''module-name'' is how kdesvn-build refers to the module. It should match the name of the module you are downloading from the source repository. Base KDE modules are listed [http://websvn.kde.org/trunk/KDE/ in WebSVN]. Other modules are also available [http://websvn.kde.org/trunk/ in WebSVN].

One exception is that modules downloaded from git can have any module name you'd like that isn't already used, as kdesvn-build determines their download location using a specific ''repository'' option.

For each module you can specify options, in the same fashion as for the global options. Most of the time, if you set an option for a module, it completely overrides the global option, if any.

However, the cmake-options for a module is added to the global cmake-options, instead of replacing it, which allows you to avoid having to give the same cmake-options for all of your modules.

{{tip|If you need to disable a global cmake-option, you can specify it again for the module you need to disable it for, and give it the opposite value. For instance, if you were using CMAKE_BUILD_TYPE=debugfull globally but wanted Release mode for kdebindings, }}

{{tip|If you get the warning from kdesvn-build that a certain module is not listed in the kdesvn-buildrc, make sure that you've added it to the kdesvn-buildrc, even if you have no options for it. If it's already in the kdesvn-buildrc, make sure you spelled the module name right on the command line.}}

==== qt-copy ====

The qt-copy module is special in that it uses configure-options instead of cmake-options, and it never inherits compilation flags that are set globally, since Qt uses a different build system than KDE software does. The sample kdesvn-buildrc contains a useful set of default configure flags, but if you aren't using qt-copy, you can simply comment the entire qt-copy module out.

Since Nokia's Qt is developed using git instead of Subversion, you must specify the ''repository'' option for qt-copy to choose which version of Qt you will use:

{|
|+ Qt Variants
|-
! Edition to build !! Repository to use
|-
| Official Nokia Qt || git://gitorious.org/qt/qt.git
|-
| Slightly modified Qt with KDE-specific patches and bugfixes (recommended if you're going to the trouble anyways) || git://gitorious.org/+kde-developers/qt/kde-qt.git
|}

Either way you should specify a ''branch'' of ''master'' to choose the default version.

If you choose kde-qt make sure to look at the README.kde-qt after kdesvn-build downloads the module for you as well!

=== Location ===

kdesvn-build will search in several locations for your rc file.

# First, kdesvn-build will look for a file called {{path|kdesvn-buildrc}} in ''the current directory''. Notice that in this situation there is no leading dot on the filename. This allows you to control the build based on what directory you're in, which would be useful for maintaining two different Subversion installs.
# If no kdesvn-buildrc is found, kdesvn-build will look for a {{path|~/.kdesvn-buildrc}}. Notice there '''is''' a leading dot on the filename in this situation. This is the standard Linux/UNIX convention for configuration files stored in the home directory, and marks this as a hidden file. So if you try to find the file in Dolphin or Konqueror, you may need to Show Hidden Files first. This controls the default configuration kdesvn-build will use, no matter what directory you run kdesvn-build from.
# If you specify the --rc-file option to kdesvn-build, kdesvn-build will try to read the given kdesvn-buildrc file instead of the default ones. This is also independent of what directory kdesvn-build is run in. But, you must remember to pass this option every time, so it is only useful for testing or for a one-time-only run.

=== Making changes ===

When you make changes to values in your kdesvn-buildrc, they may not always be picked up immediately. For example, if you change cmake-options but kdesvn-build has no reason to run CMake again, then you'll still be building with your old cmake-options.

{{note|This is only partially true -- kdesvn-build will be able to note that some values have changed and automatically re-run affected build portions as appropriate, but this advice still applies until this feature has been integrated for all options}}

The safest way to ensure that a change to your module's options is picked up is to use the --refresh-build option when rebuilding a module. This option causes kdesvn-build to completely rebuild the given module, which includes running cmake and clearing out the build directory.

Using --refresh-build takes the most time. Often, it is enough to use --reconfigure instead of --refresh-build, which runs CMake but does not clear out the build directory. But if --reconfigure doesn't work you'll end up doing --refresh-build anyways.

On the other hand, if you change the svn-server option to move where kdesvn-build is downloading from, you need to run kdesvn-build one time with the --svn-only option, so that kdesvn-build can perform the correct "svn switch" command.

=== Conclusion ===

The kdesvn-buildrc file is one of the major reasons to use kdesvn-build instead of building manually, as it will allow you to specify build settings to use all of the time instead of having to always remember to type in the correct command line settings and export the right environment variables. There are many more options than the ones covered here, which are mostly [http://kdesvn-build.kde.org/documentation/ detailed at the kdesvn-build documentation]. However, these options are enough to get you a working KDE installation.

Getting Started/Build/kdesrc-build-config

2012-02-11T16:39:30Z

Tstaerk: /* Module configuration */

== kdesvn-buildrc ==

=== Introduction ===

The [[Getting_Started/Build/kdesvn-build|kdesvn-build]] program, which is used to download, build, and install [http://www.kde.org/ KDE] from the [http://websvn.kde.org/ KDE source repository], uses a file called {{path|kdesvn-buildrc}} in order to control what is downloaded and built, what options are used, and where KDE is installed to.

This is a description of how to use {{path|kdesvn-buildrc}}.

=== Creating your configuration ===

The kdesvn-build download will include a file called {{path|kdesvn-buildrc-sample}}, which is a sample configuration file suitable for building the KDE Software Compilation (SC).

To create your configuration, it is recommended to use this file as a base since it includes the standard list of KDE modules to build, in the correct order. (You can, of course, add or remove most modules if you like).

You can use any standard text editor to edit this file, such as KWrite, nano, vi, etc.

==== Global configuration ====

Once you open the file, you will see that it starts with some comments (on lines beginning with #), and then the world "global". This starts the global configuration for the kdesvn-buildrc, which is used to specify options which are common to all of the modules.

Each option in the global section is specified in the following form:
:option-name value

Many options are already listed, with default values, and comments about the option on top. Some options have more than one sample value listed. In this situation, all but one of these will have comments. If you want to use a different sample option, simply uncomment the line by deleting the '#' at the beginning, and commenting or deleting the other lines with the same option name.

Here's a short listing of some of the important global options:

* source-dir: This option controls where kdesvn-build will download the sources to. In addition, most other directories that kdesvn-build uses will be subdirectories of this directory by default, so it is a kind of "kdesvn-build prefix". The default value is {{path|~/kdesvn}}, which downloads the source in a subdirectory under your home directory.
* build-dir: This controls where kdesvn-build actually builds the various modules. Normally it is the directory {{path|build}} under your source directory.
* kdedir: This controls where the KDE SC (and the various supporting modules such as kdesupport) get installed to. The default is {{path|~/kde}}, which installs to your home directory.

{{note|As you can see, there are three different major directories, source, build, and install. The build directory is used to keep the source directory clean and to hold intermediate files that don't get installed}}

{{tip|You can use ~/ in these options to represent your home directory}}

* qtdir: This controls where Qt 4 is assumed to be. If you use the qt-copy module, it also controls where qt-copy is installed to. Default is {{path|~/qt4}}, which installs qt-copy to your home directory.

{{tip|qt-copy is a module specifically for building Nokia's Qt toolkit. See [[#qt-copy]] below for information about what is special.}}

* cmake-options: This controls what [[Development/Tutorials/CMake#Command_Line_Variables|options]] are passed to CMake for ''every'' KDE module. For instance, if you want to enable full debugging information, you could set:
:cmake-options -DCMAKE_BUILD_TYPE=debugfull

* make-options: This is used to pass command line options to the make command, which is what actually performs the build. The most likely option is -jN, where N is the number of jobs to perform at once. If you have a system with more than one CPU, it is recommended to use N = number_of_CPUs + 1. For instance, -j3 on a dual core machine or -j5 on a quad-core. You can lower this number if your system is sluggish during the build, but raising it won't buy you much in build speed.

* make-install-prefix: This is used to allow a program to run make install on your behalf. Normally with would be the sudo program, which is used to perform actions with administrator permissions. You only need this for the following:
# You want to install KDE to the system and not your home directory.
# Some installed files require elevated permissions to work properly (this is true for kdebase, and some files in kdelibs).

If this ''is'' the case for you, you can use this option (either globally, or for each module) to run make install using sudo, or su, etc.

==== Module configuration ====

After the global options are all done, you'll see the line "end global", which lets kdesvn-build know that all of the global options have been read.

Next in the kdesvn-buildrc are the module options. First off, modules are listed in the file, in the order they are to be built and installed. Each module is listed in the following format:
:module ''module-name''
::module-options
:end module

The ''module-name'' is how kdesvn-build refers to the module. It should match the name of the module you are downloading from the source repository. Base KDE modules are listed [http://websvn.kde.org/trunk/KDE/ in WebSVN]. Other modules are also available [http://websvn.kde.org/trunk/ in WebSVN].

One exception is that modules downloaded from git can have any module name you'd like that isn't already used, as kdesvn-build determines their download location using a specific ''repository'' option.

For each module you can specify options, in the same fashion as for the global options. Most of the time, if you set an option for a module, it completely overrides the global option, if any.

However, the cmake-options for a module is added to the global cmake-options, instead of replacing it, which allows you to avoid having to give the same cmake-options for all of your modules.

{{tip|If you need to disable a global cmake-option, you can specify it again for the module you need to disable it for, and give it the opposite value. }}

{{tip|If you get the warning from kdesvn-build that a certain module is not listed in the kdesvn-buildrc, make sure that you've added it to the kdesvn-buildrc, even if you have no options for it. If it's already in the kdesvn-buildrc, make sure you spelled the module name right on the command line.}}

==== qt-copy ====

The qt-copy module is special in that it uses configure-options instead of cmake-options, and it never inherits compilation flags that are set globally, since Qt uses a different build system than KDE software does. The sample kdesvn-buildrc contains a useful set of default configure flags, but if you aren't using qt-copy, you can simply comment the entire qt-copy module out.

Since Nokia's Qt is developed using git instead of Subversion, you must specify the ''repository'' option for qt-copy to choose which version of Qt you will use:

{|
|+ Qt Variants
|-
! Edition to build !! Repository to use
|-
| Official Nokia Qt || git://gitorious.org/qt/qt.git
|-
| Slightly modified Qt with KDE-specific patches and bugfixes (recommended if you're going to the trouble anyways) || git://gitorious.org/+kde-developers/qt/kde-qt.git
|}

Either way you should specify a ''branch'' of ''master'' to choose the default version.

If you choose kde-qt make sure to look at the README.kde-qt after kdesvn-build downloads the module for you as well!

=== Location ===

kdesvn-build will search in several locations for your rc file.

# First, kdesvn-build will look for a file called {{path|kdesvn-buildrc}} in ''the current directory''. Notice that in this situation there is no leading dot on the filename. This allows you to control the build based on what directory you're in, which would be useful for maintaining two different Subversion installs.
# If no kdesvn-buildrc is found, kdesvn-build will look for a {{path|~/.kdesvn-buildrc}}. Notice there '''is''' a leading dot on the filename in this situation. This is the standard Linux/UNIX convention for configuration files stored in the home directory, and marks this as a hidden file. So if you try to find the file in Dolphin or Konqueror, you may need to Show Hidden Files first. This controls the default configuration kdesvn-build will use, no matter what directory you run kdesvn-build from.
# If you specify the --rc-file option to kdesvn-build, kdesvn-build will try to read the given kdesvn-buildrc file instead of the default ones. This is also independent of what directory kdesvn-build is run in. But, you must remember to pass this option every time, so it is only useful for testing or for a one-time-only run.

=== Making changes ===

When you make changes to values in your kdesvn-buildrc, they may not always be picked up immediately. For example, if you change cmake-options but kdesvn-build has no reason to run CMake again, then you'll still be building with your old cmake-options.

{{note|This is only partially true -- kdesvn-build will be able to note that some values have changed and automatically re-run affected build portions as appropriate, but this advice still applies until this feature has been integrated for all options}}

The safest way to ensure that a change to your module's options is picked up is to use the --refresh-build option when rebuilding a module. This option causes kdesvn-build to completely rebuild the given module, which includes running cmake and clearing out the build directory.

Using --refresh-build takes the most time. Often, it is enough to use --reconfigure instead of --refresh-build, which runs CMake but does not clear out the build directory. But if --reconfigure doesn't work you'll end up doing --refresh-build anyways.

On the other hand, if you change the svn-server option to move where kdesvn-build is downloading from, you need to run kdesvn-build one time with the --svn-only option, so that kdesvn-build can perform the correct "svn switch" command.

=== Conclusion ===

The kdesvn-buildrc file is one of the major reasons to use kdesvn-build instead of building manually, as it will allow you to specify build settings to use all of the time instead of having to always remember to type in the correct command line settings and export the right environment variables. There are many more options than the ones covered here, which are mostly [http://kdesvn-build.kde.org/documentation/ detailed at the kdesvn-build documentation]. However, these options are enough to get you a working KDE installation.

Getting Started/Build/kdesrc-build-config

2012-02-11T16:38:53Z

Tstaerk:

== kdesvn-buildrc ==

=== Introduction ===

The [[Getting_Started/Build/kdesvn-build|kdesvn-build]] program, which is used to download, build, and install [http://www.kde.org/ KDE] from the [http://websvn.kde.org/ KDE source repository], uses a file called {{path|kdesvn-buildrc}} in order to control what is downloaded and built, what options are used, and where KDE is installed to.

This is a description of how to use {{path|kdesvn-buildrc}}.

=== Creating your configuration ===

The kdesvn-build download will include a file called {{path|kdesvn-buildrc-sample}}, which is a sample configuration file suitable for building the KDE Software Compilation (SC).

To create your configuration, it is recommended to use this file as a base since it includes the standard list of KDE modules to build, in the correct order. (You can, of course, add or remove most modules if you like).

You can use any standard text editor to edit this file, such as KWrite, nano, vi, etc.

==== Global configuration ====

Once you open the file, you will see that it starts with some comments (on lines beginning with #), and then the world "global". This starts the global configuration for the kdesvn-buildrc, which is used to specify options which are common to all of the modules.

Each option in the global section is specified in the following form:
:option-name value

Many options are already listed, with default values, and comments about the option on top. Some options have more than one sample value listed. In this situation, all but one of these will have comments. If you want to use a different sample option, simply uncomment the line by deleting the '#' at the beginning, and commenting or deleting the other lines with the same option name.

Here's a short listing of some of the important global options:

* source-dir: This option controls where kdesvn-build will download the sources to. In addition, most other directories that kdesvn-build uses will be subdirectories of this directory by default, so it is a kind of "kdesvn-build prefix". The default value is {{path|~/kdesvn}}, which downloads the source in a subdirectory under your home directory.
* build-dir: This controls where kdesvn-build actually builds the various modules. Normally it is the directory {{path|build}} under your source directory.
* kdedir: This controls where the KDE SC (and the various supporting modules such as kdesupport) get installed to. The default is {{path|~/kde}}, which installs to your home directory.

{{note|As you can see, there are three different major directories, source, build, and install. The build directory is used to keep the source directory clean and to hold intermediate files that don't get installed}}

{{tip|You can use ~/ in these options to represent your home directory}}

* qtdir: This controls where Qt 4 is assumed to be. If you use the qt-copy module, it also controls where qt-copy is installed to. Default is {{path|~/qt4}}, which installs qt-copy to your home directory.

{{tip|qt-copy is a module specifically for building Nokia's Qt toolkit. See [[#qt-copy]] below for information about what is special.}}

* cmake-options: This controls what [[Development/Tutorials/CMake#Command_Line_Variables|options]] are passed to CMake for ''every'' KDE module. For instance, if you want to enable full debugging information, you could set:
:cmake-options -DCMAKE_BUILD_TYPE=debugfull

* make-options: This is used to pass command line options to the make command, which is what actually performs the build. The most likely option is -jN, where N is the number of jobs to perform at once. If you have a system with more than one CPU, it is recommended to use N = number_of_CPUs + 1. For instance, -j3 on a dual core machine or -j5 on a quad-core. You can lower this number if your system is sluggish during the build, but raising it won't buy you much in build speed.

* make-install-prefix: This is used to allow a program to run make install on your behalf. Normally with would be the sudo program, which is used to perform actions with administrator permissions. You only need this for the following:
# You want to install KDE to the system and not your home directory.
# Some installed files require elevated permissions to work properly (this is true for kdebase, and some files in kdelibs).

If this ''is'' the case for you, you can use this option (either globally, or for each module) to run make install using sudo, or su, etc.

==== Module configuration ====

After the global options are all done, you'll see the line "end global", which lets kdesvn-build know that all of the global options have been read.

Next in the kdesvn-buildrc are the module options. First off, modules are listed in the file, in the order they are to be built and installed. Each module is listed in the following format:
:module ''module-name''
::module-options
:end module

The ''module-name'' is how kdesvn-build refers to the module. It should match the name of the module you are downloading from the source repository. Base KDE modules are listed [http://websvn.kde.org/trunk/KDE/ in WebSVN]. Other modules are also available [http://websvn.kde.org/trunk/ in WebSVN].

One exception is that modules downloaded from git can have any module name you'd like that isn't already used, as kdesvn-build determines their download location using a specific ''repository'' option.

For each module you can specify options, in the same fashion as for the global options. Most of the time, if you set an option for a module, it completely overrides the global option, if any.

However, the cmake-options for a module is added to the global cmake-options, instead of replacing it, which allows you to avoid having to give the same cmake-options for all of your modules.

{{tip|I}}

{{tip|If you get the warning from kdesvn-build that a certain module is not listed in the kdesvn-buildrc, make sure that you've added it to the kdesvn-buildrc, even if you have no options for it. If it's already in the kdesvn-buildrc, make sure you spelled the module name right on the command line.}}

==== qt-copy ====

The qt-copy module is special in that it uses configure-options instead of cmake-options, and it never inherits compilation flags that are set globally, since Qt uses a different build system than KDE software does. The sample kdesvn-buildrc contains a useful set of default configure flags, but if you aren't using qt-copy, you can simply comment the entire qt-copy module out.

Since Nokia's Qt is developed using git instead of Subversion, you must specify the ''repository'' option for qt-copy to choose which version of Qt you will use:

{|
|+ Qt Variants
|-
! Edition to build !! Repository to use
|-
| Official Nokia Qt || git://gitorious.org/qt/qt.git
|-
| Slightly modified Qt with KDE-specific patches and bugfixes (recommended if you're going to the trouble anyways) || git://gitorious.org/+kde-developers/qt/kde-qt.git
|}

Either way you should specify a ''branch'' of ''master'' to choose the default version.

If you choose kde-qt make sure to look at the README.kde-qt after kdesvn-build downloads the module for you as well!

=== Location ===

kdesvn-build will search in several locations for your rc file.

# First, kdesvn-build will look for a file called {{path|kdesvn-buildrc}} in ''the current directory''. Notice that in this situation there is no leading dot on the filename. This allows you to control the build based on what directory you're in, which would be useful for maintaining two different Subversion installs.
# If no kdesvn-buildrc is found, kdesvn-build will look for a {{path|~/.kdesvn-buildrc}}. Notice there '''is''' a leading dot on the filename in this situation. This is the standard Linux/UNIX convention for configuration files stored in the home directory, and marks this as a hidden file. So if you try to find the file in Dolphin or Konqueror, you may need to Show Hidden Files first. This controls the default configuration kdesvn-build will use, no matter what directory you run kdesvn-build from.
# If you specify the --rc-file option to kdesvn-build, kdesvn-build will try to read the given kdesvn-buildrc file instead of the default ones. This is also independent of what directory kdesvn-build is run in. But, you must remember to pass this option every time, so it is only useful for testing or for a one-time-only run.

=== Making changes ===

When you make changes to values in your kdesvn-buildrc, they may not always be picked up immediately. For example, if you change cmake-options but kdesvn-build has no reason to run CMake again, then you'll still be building with your old cmake-options.

{{note|This is only partially true -- kdesvn-build will be able to note that some values have changed and automatically re-run affected build portions as appropriate, but this advice still applies until this feature has been integrated for all options}}

The safest way to ensure that a change to your module's options is picked up is to use the --refresh-build option when rebuilding a module. This option causes kdesvn-build to completely rebuild the given module, which includes running cmake and clearing out the build directory.

Using --refresh-build takes the most time. Often, it is enough to use --reconfigure instead of --refresh-build, which runs CMake but does not clear out the build directory. But if --reconfigure doesn't work you'll end up doing --refresh-build anyways.

On the other hand, if you change the svn-server option to move where kdesvn-build is downloading from, you need to run kdesvn-build one time with the --svn-only option, so that kdesvn-build can perform the correct "svn switch" command.

=== Conclusion ===

The kdesvn-buildrc file is one of the major reasons to use kdesvn-build instead of building manually, as it will allow you to specify build settings to use all of the time instead of having to always remember to type in the correct command line settings and export the right environment variables. There are many more options than the ones covered here, which are mostly [http://kdesvn-build.kde.org/documentation/ detailed at the kdesvn-build documentation]. However, these options are enough to get you a working KDE installation.

Getting Started/Build/kdesrc-build-config

2012-02-11T16:37:51Z

Tstaerk:

== kdesvn-buildrc ==

=== Introduction ===

The [[Getting_Started/Build/kdesvn-build|kdesvn-build]] program, which is used to download, build, and install [http://www.kde.org/ KDE] from the [http://websvn.kde.org/ KDE source repository], uses a file called {{path|kdesvn-buildrc}} in order to control what is downloaded and built, what options are used, and where KDE is installed to.

This is a description of how to use {{path|kdesvn-buildrc}}.

=== Creating your configuration ===

The kdesvn-build download will include a file called {{path|kdesvn-buildrc-sample}}, which is a sample configuration file suitable for building the KDE Software Compilation (SC).

To create your configuration, it is recommended to use this file as a base since it includes the standard list of KDE modules to build, in the correct order. (You can, of course, add or remove most modules if you like).

You can use any standard text editor to edit this file, such as KWrite, nano, vi, etc.

==== Global configuration ====

Once you open the file, you will see that it starts with some comments (on lines beginning with #), and then the world "global". This starts the global configuration for the kdesvn-buildrc, which is used to specify options which are common to all of the modules.

Each option in the global section is specified in the following form:
:option-name value

Many options are already listed, with default values, and comments about the option on top. Some options have more than one sample value listed. In this situation, all but one of these will have comments. If you want to use a different sample option, simply uncomment the line by deleting the '#' at the beginning, and commenting or deleting the other lines with the same option name.

Here's a short listing of some of the important global options:

* source-dir: This option controls where kdesvn-build will download the sources to. In addition, most other directories that kdesvn-build uses will be subdirectories of this directory by default, so it is a kind of "kdesvn-build prefix". The default value is {{path|~/kdesvn}}, which downloads the source in a subdirectory under your home directory.
* build-dir: This controls where kdesvn-build actually builds the various modules. Normally it is the directory {{path|build}} under your source directory.
* kdedir: This controls where the KDE SC (and the various supporting modules such as kdesupport) get installed to. The default is {{path|~/kde}}, which installs to your home directory.

{{note|As you can see, there are three different major directories, source, build, and install. The build directory is used to keep the source directory clean and to hold intermediate files that don't get installed}}

{{tip|You can use ~/ in these options to represent your home directory}}

* qtdir: This controls where Qt 4 is assumed to be. If you use the qt-copy module, it also controls where qt-copy is installed to. Default is {{path|~/qt4}}, which installs qt-copy to your home directory.

{{tip|qt-copy is a module specifically for building Nokia's Qt toolkit. See [[#qt-copy]] below for information about what is special.}}

* cmake-options: This controls what [[Development/Tutorials/CMake#Command_Line_Variables|options]] are passed to CMake for ''every'' KDE module. For instance, if you want to enable full debugging information, you could set:
:cmake-options -DCMAKE_BUILD_TYPE=debugfull

* make-options: This is used to pass command line options to the make command, which is what actually performs the build. The most likely option is -jN, where N is the number of jobs to perform at once. If you have a system with more than one CPU, it is recommended to use N = number_of_CPUs + 1. For instance, -j3 on a dual core machine or -j5 on a quad-core. You can lower this number if your system is sluggish during the build, but raising it won't buy you much in build speed.

* make-install-prefix: This is used to allow a program to run make install on your behalf. Normally with would be the sudo program, which is used to perform actions with administrator permissions. You only need this for the following:
# You want to install KDE to the system and not your home directory.
# Some installed files require elevated permissions to work properly (this is true for kdebase, and some files in kdelibs).

If this ''is'' the case for you, you can use this option (either globally, or for each module) to run make install using sudo, or su, etc.

==== Module configuration ====

After the global options are all done, you'll see the line "end global", which lets kdesvn-build know that all of the global options have been read.

Next in the kdesvn-buildrc are the module options. First off, modules are listed in the file, in the order they are to be built and installed. Each module is listed in the following format:
:module ''module-name''
::module-options
:end module

The ''module-name'' is how kdesvn-build refers to the module. It should match the name of the module you are downloading from the source repository. Base KDE modules are listed [http://websvn.kde.org/trunk/KDE/ in WebSVN]. Other modules are also available [http://websvn.kde.org/trunk/ in WebSVN].

One exception is that modules downloaded from git can have any module name you'd like that isn't already used, as kdesvn-build determines their download location using a specific ''repository'' option.

For each module you can specify options, in the same fashion as for the global options. Most of the time, if you set an option for a module, it completely overrides the global option, if any.

However, the cmake-options for a module is added to the global cmake-options, instead of replacing it, which allows you to avoid having to give the same cmake-options for all of your modules.

{{tip|If you need to disable a global cmake-option, you can specify it again for the module you need to disable it for, and give it the opposite value. For instance, if you were using CMAKE_BUILD_TYPE=debugfull globally but wanted Release mode for kdebindings, you could set cmake-options -DCMAKE_BUILD_TYPE=Release for kdebindings.}}

{{tip|If you get the warning from kdesvn-build that a certain module is not listed in the kdesvn-buildrc, make sure that you've added it to the kdesvn-buildrc, even if you have no options for it. If it's already in the kdesvn-buildrc, make sure you spelled the module name right on the command line.}}

==== qt-copy ====

The qt-copy module is special in that it uses configure-options instead of cmake-options, and it never inherits compilation flags that are set globally, since Qt uses a different build system than KDE software does. The sample kdesvn-buildrc contains a useful set of default configure flags, but if you aren't using qt-copy, you can simply comment the entire qt-copy module out.

Since Nokia's Qt is developed using git instead of Subversion, you must specify the ''repository'' option for qt-copy to choose which version of Qt you will use:

{|
|+ Qt Variants
|-
! Edition to build !! Repository to use
|-
| Official Nokia Qt || git://gitorious.org/qt/qt.git
|-
| Slightly modified Qt with KDE-specific patches and bugfixes (recommended if you're going to the trouble anyways) || git://gitorious.org/+kde-developers/qt/kde-qt.git
|}

Either way you should specify a ''branch'' of ''master'' to choose the default version.

If you choose kde-qt make sure to look at the README.kde-qt after kdesvn-build downloads the module for you as well!

=== Location ===

kdesvn-build will search in several locations for your rc file.

# First, kdesvn-build will look for a file called {{path|kdesvn-buildrc}} in ''the current directory''. Notice that in this situation there is no leading dot on the filename. This allows you to control the build based on what directory you're in, which would be useful for maintaining two different Subversion installs.
# If no kdesvn-buildrc is found, kdesvn-build will look for a {{path|~/.kdesvn-buildrc}}. Notice there '''is''' a leading dot on the filename in this situation. This is the standard Linux/UNIX convention for configuration files stored in the home directory, and marks this as a hidden file. So if you try to find the file in Dolphin or Konqueror, you may need to Show Hidden Files first. This controls the default configuration kdesvn-build will use, no matter what directory you run kdesvn-build from.
# If you specify the --rc-file option to kdesvn-build, kdesvn-build will try to read the given kdesvn-buildrc file instead of the default ones. This is also independent of what directory kdesvn-build is run in. But, you must remember to pass this option every time, so it is only useful for testing or for a one-time-only run.

=== Making changes ===

When you make changes to values in your kdesvn-buildrc, they may not always be picked up immediately. For example, if you change cmake-options but kdesvn-build has no reason to run CMake again, then you'll still be building with your old cmake-options.

{{note|This is only partially true -- kdesvn-build will be able to note that some values have changed and automatically re-run affected build portions as appropriate, but this advice still applies until this feature has been integrated for all options}}

The safest way to ensure that a change to your module's options is picked up is to use the --refresh-build option when rebuilding a module. This option causes kdesvn-build to completely rebuild the given module, which includes running cmake and clearing out the build directory.

Using --refresh-build takes the most time. Often, it is enough to use --reconfigure instead of --refresh-build, which runs CMake but does not clear out the build directory. But if --reconfigure doesn't work you'll end up doing --refresh-build anyways.

On the other hand, if you change the svn-server option to move where kdesvn-build is downloading from, you need to run kdesvn-build one time with the --svn-only option, so that kdesvn-build can perform the correct "svn switch" command.

=== Conclusion ===

The kdesvn-buildrc file is one of the major reasons to use kdesvn-build instead of building manually, as it will allow you to specify build settings to use all of the time instead of having to always remember to type in the correct command line settings and export the right environment variables. There are many more options than the ones covered here, which are mostly [http://kdesvn-build.kde.org/documentation/ detailed at the kdesvn-build documentation]. However, these options are enough to get you a working KDE installation.

Getting Started/Build/kdesrc-build-config

2012-02-11T16:35:56Z

Tstaerk: /* Module configuration */

== kdesvn-buildrc ==

=== Introduction ===

The [[Getting_Started/Build/kdesvn-build|kdesvn-build]] program, which is used to download, build, and install [http://www.kde.org/ KDE] from the [http://websvn.kde.org/ KDE source repository], uses a file called {{path|kdesvn-buildrc}} in order to control what is downloaded and built, what options are used, and where KDE is installed to.

This is a description of how to use {{path|kdesvn-buildrc}}.

=== Creating your configuration ===

The kdesvn-build download will include a file called {{path|kdesvn-buildrc-sample}}, which is a sample configuration file suitable for building the KDE Software Compilation (SC).

To create your configuration, it is recommended to use this file as a base since it includes the standard list of KDE modules to build, in the correct order. (You can, of course, add or remove most modules if you like).

You can use any standard text editor to edit this file, such as KWrite, nano, vi, etc.

==== Global configuration ====

Once you open the file, you will see that it starts with some comments (on lines beginning with #), and then the world "global". This starts the global configuration for the kdesvn-buildrc, which is used to specify options which are common to all of the modules.

Each option in the global section is specified in the following form:
:option-name value

Many options are already listed, with default values, and comments about the option on top. Some options have more than one sample value listed. In this situation, all but one of these will have comments. If you want to use a different sample option, simply uncomment the line by deleting the '#' at the beginning, and commenting or deleting the other lines with the same option name.

Here's a short listing of some of the important global options:

* source-dir: This option controls where kdesvn-build will download the sources to. In addition, most other directories that kdesvn-build uses will be subdirectories of this directory by default, so it is a kind of "kdesvn-build prefix". The default value is {{path|~/kdesvn}}, which downloads the source in a subdirectory under your home directory.
* build-dir: This controls where kdesvn-build actually builds the various modules. Normally it is the directory {{path|build}} under your source directory.
* kdedir: This controls where the KDE SC (and the various supporting modules such as kdesupport) get installed to. The default is {{path|~/kde}}, which installs to your home directory.

{{note|As you can see, there are three different major directories, source, build, and install. The build directory is used to keep the source directory clean and to hold intermediate files that don't get installed}}

{{tip|You can use ~/ in these options to represent your home directory}}

* qtdir: This controls where Qt 4 is assumed to be. If you use the qt-copy module, it also controls where qt-copy is installed to. Default is {{path|~/qt4}}, which installs qt-copy to your home directory.

{{tip|qt-copy is a module specifically for building Nokia's Qt toolkit. See [[#qt-copy]] below for information about what is special.}}

* cmake-options: This controls what [[Development/Tutorials/CMake#Command_Line_Variables|options]] are passed to CMake for ''every'' KDE module. For instance, if you want to enable full debugging information, you could set:
:cmake-options -DCMAKE_BUILD_TYPE=debugfull

* make-options: This is used to pass command line options to the make command, which is what actually performs the build. The most likely option is -jN, where N is the number of jobs to perform at once. If you have a system with more than one CPU, it is recommended to use N = number_of_CPUs + 1. For instance, -j3 on a dual core machine or -j5 on a quad-core. You can lower this number if your system is sluggish during the build, but raising it won't buy you much in build speed.

* make-install-prefix: This is used to allow a program to run make install on your behalf. Normally with would be the sudo program, which is used to perform actions with administrator permissions. You only need this for the following:
# You want to install KDE to the system and not your home directory.
# Some installed files require elevated permissions to work properly (this is true for kdebase, and some files in kdelibs).

If this ''is'' the case for you, you can use this option (either globally, or for each module) to run make install using sudo, or su, etc.

==== Module configuration ====

After the global options are all done, you'll see the line "end global", which lets kdesvn-build know that all of the global options have been read.

Next in the kdesvn-buildrc are the module options. First off, modules are listed in the file, in the order they are to be built and installed. Each module is listed in the following format:
:module ''module-name''
::module-options
:end module

The ''module-name'' is how kdesvn-build refers to the module. It should match the name of the module you are downloading from the source repository. Base KDE modules are listed [http://websvn.kde.org/trunk/KDE/ in WebSVN]. Other modules are also available [http://websvn.kde.org/trunk/ in WebSVN].

One exception is that modules downloaded from git can have any module name you'd like that isn't already used, as kdesvn-build determines their download location using a specific ''repository'' option.

For each module you can specify options, in the same fashion as for the global options. Most of the time, if you set an option for a module, it completely overrides the global option, if any.

However, the cmake-options for a module is added to the global cmake-options, instead of replacing it, which allows you to avoid having to give the same cmake-options for all of your modules.

{{tip|If you need to disable a global cmake-option, you can specify it again for the module you need to disable it for, and give it the opposite value. For instance, if you were using CMAKE_BUILD_TYPE=debugfull globally but wanted Release mode for kdebindings, you could set cmake-options -DCMAKE_BUILD_TYPE=Release for kdebindings.}}

{{tip|If you get the warning from kdesvn-build that a certain module is not listed in the kdesvn-buildrc, make sure that you've added it to the kdesvn-buildrc, even if you have no options for it. If it's already in the kdesvn-buildrc, make sure you spelled the module name right on the command line.}}

==== qt-copy ====

The qt-copy module is special in that it uses configure-options instead of cmake-options, and it never inherits compilation flags that are set globally, since Qt uses a different build system than KDE software does. The sample kdesvn-buildrc contains a useful set of default configure flags, but if you aren't using qt-copy, you can simply comment the entire qt-copy module out.

Since Nokia's Qt is developed using git instead of Subversion, you must specify the ''repository'' option for qt-copy to choose which version of Qt you will use:

{|
|+ Qt Variants
|-
! Edition to build !! Repository to use
|-
| Official Nokia Qt || git://gitorious.org/qt/qt.git
|-
| Slightly modified Qt with KDE-specific patches and bugfixes (recommended if you're going to the trouble anyways) || git://gitorious.org/+kde-developers/qt/kde-qt.git
|}

Either way you should specify a ''branch'' of ''master'' to choose the default version.

If you choose kde-qt make sure to look at the README.kde-qt after kdesvn-build downloads the module for you as well!

=== Location ===

kdesvn-build will search in several locations for your rc file.

# First, kdesvn-build will look for a file called {{path|kdesvn-buildrc}} in ''the current directory''. Notice that in this situation there is no leading dot on the filename. This allows you to control the build based on what directory you're in, which would be useful for maintaining two different Subversion installs.
# If no kdesvn-buildrc is found, kdesvn-build will look for a {{path|~/.kdesvn-buildrc}}. Notice there '''is''' a leading dot on the filename in this situation. This is the standard Linux/UNIX convention for configuration files stored in the home directory, and marks this as a hidden file. So if you try to find the file in Dolphin or Konqueror, you may need to Show Hidden Files first. This controls the default configuration kdesvn-build will use, no matter what directory you run kdesvn-build from.
# If you specify the --rc-file option to kdesvn-build, kdesvn-build will try to read the given kdesvn-buildrc file instead of the default ones. This is also independent of what directory kdesvn-build is run in. But, you must remember to pass this option every time, so it is only useful for testing or for a one-time-only run.

=== Making changes ===

When you make changes to values in your kdesvn-buildrc, they may not always be picked up immediately. For example, if you change cmake-options but kdesvn-build has no reason to run CMake again, then you'll still be building with your old cmake-options.

{{note|This is only partially true -- kdesvn-build will be able to note that some values have changed and automatically re-run affected build portions as appropriate, but this advice still applies until this feature has been integrated for all options}}

The safest way to ensure that a change to your module's options is picked up is to use the --refresh-build option when rebuilding a module. This option causes kdesvn-build to completely rebuild the given module, which includes running cmake and clearing out the build directory.

Using --refresh-build takes the most time. Often, it is enough to use --reconfigure instead of --refresh-build, which runs CMake but does not clear out the build directory. But if --reconfigure doesn't work you'll end up doing --refresh-build anyways.

On the other hand, if you change the svn-server option to move where kdesvn-build is downloading from, you need to run kdesvn-build one time with the --svn-only option, so that kdesvn-build can perform the correct "svn switch" command.

=== Conclusion ===

The kdesvn-buildrc file is one of the major reasons to use kdesvn-build instead of building manually, as it will allow you to specify build settings to use all of the time instead of having to always remember to type in the correct command line settings and export the right environment variables. There are many more options than the ones covered here, which are mostly [http://kdesvn-build.kde.org/documentation/ detailed at the kdesvn-build documentation]. However, these options are enough to get you a working KDE installation.

Getting Started/Build/kdesrc-build

2012-02-11T16:33:20Z

Tstaerk: /* Download and install kdesrc-build */

{{Template:I18n/Language Navigation Bar|Getting_Started/Build/kdesrc-build}}

{{note|It is possible to build KDE 3 using older versions of kdesrc-build, but this is not described here.}}

== Building KDE using the kdesrc-build tool ==

=== Introduction to kdesrc-build ===

[http://kdesrc-build.kde.org/ kdesrc-build] (formerly kdesvn-build) is a tool to allow users and developers to easily download and build the latest versions of the KDE Software Compilation (KDE SC) from the KDE source code repositories. It automates the following tasks and more:

* Performing the initial checkout.
* Handling updates for modules that are already checked out.
* Setting up the build system for the module.
* Performing the build and install.
* Specifying your CMake options or configure flags (so you don't have to remember them every time).
* Logging build errors so you can review them easier for troubleshooting.

It is not the end-all for your troubles building KDE, [[../Troubleshooting|Troubleshooting]] still applies. Many errors that occur using other methods occur here too, you read the log files that are stored for you.

=== Why use kdesrc-build? ===

So why use kdesrc-build? There are several reasons you may like to use it:

# Less manual editing of commands. Instead of having to remember to add the correct options to the cmake command line or configure command, you can setup the options once and then kdesrc-build will use your settings from then on, saving you from wasting time because you forgot to enable a setting.
# Command logging to help debug build failures. kdesrc-build logs all command outputs to a file. This has several advantages:
## When a module fails to build, you already have the error output saved to disk, ready to be viewed and compared with other error messages to aid debugging.
## Quieter output. Even with CMake, the output of Qt or a KDE SC module build can be extensive. kdesrc-build does not show the details of a module build (but will show the progress), instead an overview of the build process is displayed.
# It's just easier. Instead of having to learn how to use the Subversion and git tools, and how to setup a KDE build system, you can specify what modules you want build, where to install them to, and any other options you want and then have kdesrc-build actually do it, even while you're away from the computer or busy doing other things.
# It's easy to step in yourself. kdesrc-build uses a standard source and build directory layout, and calls the same commands you would. So kdesrc-build will not interfere with you performing the build or editing the source yourself if you so choose.

=== Setting up ===

==== Prerequisites ====
kdesrc-build is fairly easy to install and setup, but you also need to have the right software installed to build KDE. The requirements to build KDE are available as follows:

* KDE 4: [[../Requirements|KDE 4 Requirements]]

kdesrc-build requires Perl 5.8 or higher. It is installed by default with most distributions, and is included in the link above. Check your version of Perl with:
<syntaxhighlight lang="text">perl -v</syntaxhighlight>

You will also need [https://github.com/gisle/libwww-perl#readme libwww], a collection of Perl Internet-related modules.

{{note|kdesrc-build is developed on a Linux system, but it should work on the various BSD distributions as well (although GNU tools may be required).}}

==== Download and install kdesrc-build ====
Once your system is setup to be able to compile the KDE SC, you can download kdesrc-build from its website, [http://kdesrc-build.kde.org/ kdesrc-build.kde.org]. The file you download will contain (at least) the kdesrc-build script and a sample configuration file. Installing kdesrc-build is as simple as saving the file and making it executable. If you'd like, you can move it to a directory in your PATH, however for this example we'll put it into the KDE source directory that we use (~/kdesrc)

<syntaxhighlight lang="bash">
mkdir -p ~/kdesrc &&
cd ~/kdesrc &&
tar xjvf ~/path/to/kdesrc-build-1.14.1.tar.bz2 &&
cp kdesrc-build-1.14.1/kdesrc-build .
</syntaxhighlight>

Alternatively, the newest kdesrc-build script (and sample config file) can be pulled directly from git:
<syntaxhighlight lang="bash">
git clone git://anongit.kde.org/kdesrc-build.git ~/kdesrc
</syntaxhighlight>

==== Setup the configuration ====
Now you should [[Getting Started/Build/kdesrc-buildrc|setup your configuration]]. For the most part the defaults in the included kdesrc-buildrc-sample should be sufficient.

<syntaxhighlight lang="bash">
cp ~/kdesrc/kdesrc-build-1.14.1/kdesrc-buildrc-sample ~/.kdesrc-buildrc
# Now edit the ~/.kdesrc-buildrc
</syntaxhighlight>

{{tip|Note that the config file's name begins with a leading ., making it a hidden file. You may need to show hidden files in Dolphin or Konqueror to find the configuration file to edit it. Or, you can edit the sample before copying it to ~/.kdesrc-buildrc.}}

Also, make sure that the modules you'll want to build are included. You'll want the following at the least:

* qt-copy, kdesupport, kdelibs, kdepimlibs, kdebase

Modules are built in the order they appear in your ~/.kdesrc-buildrc, so the first module should be qt-copy, kdelibs should be before any other KDE SC module, and so on.

{{note|The sample configuration file does include these modules by default, you won't need to make many changes unless you'd like to add some modules to the build by uncommenting them.}}

You may want to enable the make-install-prefix option if you are installing KDE SC or Qt to a directory that is not in your home directory. make-install-prefix allows you to run su or sudo during the make install process so you can install files as root, or set certain programs to execute with higher permissions (This is required for certain programs to execute properly).

<pre>module kdelibs
make-install-prefix sudo -S # sudo with no stdin
end module

module kdebase
make-install-prefix sudo -S
end module</pre>

If a module you'd like to build isn't already present, simply add

<pre>module <module-name>
end module</pre> at the end of the ~/.kdesrc-buildrc. <module-name> would be whatever the module is called in the software repository (for instance, kdemultimedia).

===== Git-based modules =====

Some KDE projects use the "git" source-control software instead of Subversion (as part of an ongoing migration to git). This includes software like Amarok and Konversation.

To build these modules in kdesrc-build, you just need to add a couple of lines to the module configuration. For example, konversation is developed in the Git repository at [https://projects.kde.org/projects/extragear/network/konversation/repository]. So you would just add a module (you can pick whatever name for the module you like, as long as it's not already used):

<pre>module konversation
repository git://anongit.kde.org/konversation
branch master
end module</pre>

In this case I selected the "master" branch since that is the default git branch.

Now whenever you build konversation, kdesrc-build will use git instead of Subversion.

==== Useful kdesrc-build commands ====
kdesrc-build is driven from the command line, so here's a guide to some of the more useful command line options:

<table cellpadding="2">
<tr>
<th>Option</th><th>Effect</th>
</tr>
<tr>
<td><tt><span style="white-space:nowrap;">[http://kdesrc-build.kde.org/documentation/cmdline.html#cmdline-pretend --pretend]</span></tt> (Short form <tt><span style="white-space:nowrap;">-p</span></tt>)</td>
<td>This option is like a dry run. kdesrc-build will process the options and its configuration like normal, and run through the build as normal, but instead of downloading or running the build will instead output what kdesrc-build would have done. You should always run with -p before running kdesrc-build to make sure it is doing what you expect.</td>
</tr>
<tr>
<td><tt>[http://kdesrc-build.kde.org/documentation/cmdline.html#cmdline-no-svn --no-svn]</tt> (Alt. form <tt>--no-src</tt>)</td><td>This option skips the source code update step. This is useful if you're running kdesrc-build again soon after the last update and don't want to wait to find out there were no changes.</td>
</tr>
<tr>
<td><tt>[http://kdesrc-build.kde.org/documentation/cmdline.html#cmdline-refresh-build --refresh-build]</tt></td><td>This option causes kdesrc-build to delete the current build information for the given modules and start building them again from scratch. This option takes a lot of time but gives the best chance of a successful build.</td>
</tr>
</table>

Any other non-option arguments on the command line are assumed to be modules to build (and are built in the order provided on the command line). If no modules are specified, all of the modules listed in the ~/.kdesrc-buildrc are built in the order listed in the file.

== Build ==
We're almost there. If you're happy with your settings then it's time to test out kdesrc-build. In theory things are as simple as running kdesrc-build and then coming back later. ;)

<syntaxhighlight lang="bash">
cd ~/kdesrc
./kdesrc-build
</syntaxhighlight>

You may want to test by building qt-copy first however.

<syntaxhighlight lang="bash">
cd ~/kdesrc
./kdesrc-build qt-copy
</syntaxhighlight>

{{tip|If you have the [http://www.gnu.org/software/screen/ GNU screen] program available then you should definitely use it to run kdesrc-build, as you can detach your kdesrc-build session and logout while kdesrc-build is still running.}}

If the build failed (kdesrc-build will error out with a nice bright red error message) then there are several possibilities:

# You are missing a key piece of required software (such as a development library)
# The KDE SC code being compiled is broken in some fashion to where it won't build. This is commonly due to newly committed code that worked on the developer's machine, or occasionally on Mondays (when incompatible changes are permitted to kdelibs).
# kdesrc-build is not setup properly. You may be trying to install to a directory that you have no permissions to access for instance, or you may have specified a system qtdir that does not exist.
# The module may depend on a newer version of qt-copy or kdelibs (or other module). In this case you'll have to run kdesrc-build to update the out-of-date module first.

How do you find out what the error was? The output of the failing command will be in the log directory. By default, all log output is in the {{path|log}} subdirectory of the KDE SC source directory. The log directory is laid out like this: {{path|log/date-run/module/output-file.log}}. To simplify finding the appropriate file, there are a couple of symlinks created:

{{path|log/latest}} always has the debugging output for the last time kdesrc-build was run (--pretend doesn't count toward this)
{{path|log/latest/<module>/error.log}} has the debugging output for the command that caused a module build to fail.

For instance if qt-copy just failed to build you could read the output like this:

<syntaxhighlight lang="bash">
cd ~/kderc
kwrite log/latest/qt-copy/error.log
</syntaxhighlight>

Replace kwrite with your preferred editor. Hopefully the output can guide you to resolving the problem. For instance, if the failure is a cmake output saying you're missing a library, install that library and try again. ;) For link errors you can try running a --refresh-build on the module (or if that doesn't work, required libraries like qt-copy and kdelibs).

If you're stumped by the error you may want to wait a day and try updating again, and hope that the reason for the error has been fixed. You can also try mailing the [http://www.kde.org/mailinglists/ kde-devel] mailing list to see if others know about the problem or have had similar issues.

== Running KDE ==

Assuming you got enough of the modules to build and install to have a working KDE installation, you'll still need to setup your environment correctly to run it. kdesrc-build doesn't help you out here (yet), so you should follow the instructions [[Getting_Started/Using_an_IDE_with_KDE4|here]].

Make sure to use the same paths as the ones you defined in .kdesrc-buildrc: for the KDEDIRS and KDEDIR variable use the setting of the "prefix" option (in the global section). For the QTDIR variable use the setting of the "qtdir" option.

== Keeping KDE up to date ==

Keeping your KDE installation up to date is as simple as running kdesrc-build again. Every kdesrc-build has these phases:

# Update the source code for all modules being built.
# Build and then install all the modules.

Old build directories are not deleted by default, so the build after a small update will not normally take as long as the initial build of a module. This is called "incremental make". However it may be necessary at times to perform a full rebuild due to inconsistencies between the build directory configuation and changes to the source directory. You can use the --refresh-build option to force a full rebuild.

For more information on how to take advantage of kdesrc-build, see the [http://kdesrc-build.kde.org/documentation online documentation] for kdesrc-build, which describes all of the module options and command line options available for kdesrc-build and gives tips on how to perform various useful tasks.

If you have any questions that are not answered please feel free to add them under the Discussion entry for this page and hopefully someone will be able to get the answer.

= See also =
* To browse the KDE Subversion repository, use [http://websvn.kde.org/trunk/KDE WebSVN].
* To browse any of the various KDE projects using git, you can go to [http://projects.kde.org KDE Git Projects] or to [http://gitweb.kde.org KDE Git Web].
* The Nokia Qt toolkit used by KDE can be browsed at [http://qt.gitorious.org/qt Nokia's Qt version on gitorious].

[[Category:Build_KDE]]
[[Category:Tutorial]]

Getting Started/Build/kdesrc-build

2012-02-11T16:32:36Z

Tstaerk: /* Setup the configuration */

{{Template:I18n/Language Navigation Bar|Getting_Started/Build/kdesrc-build}}

{{note|It is possible to build KDE 3 using older versions of kdesrc-build, but this is not described here.}}

== Building KDE using the kdesrc-build tool ==

=== Introduction to kdesrc-build ===

[http://kdesrc-build.kde.org/ kdesrc-build] (formerly kdesvn-build) is a tool to allow users and developers to easily download and build the latest versions of the KDE Software Compilation (KDE SC) from the KDE source code repositories. It automates the following tasks and more:

* Performing the initial checkout.
* Handling updates for modules that are already checked out.
* Setting up the build system for the module.
* Performing the build and install.
* Specifying your CMake options or configure flags (so you don't have to remember them every time).
* Logging build errors so you can review them easier for troubleshooting.

It is not the end-all for your troubles building KDE, [[../Troubleshooting|Troubleshooting]] still applies. Many errors that occur using other methods occur here too, you read the log files that are stored for you.

=== Why use kdesrc-build? ===

So why use kdesrc-build? There are several reasons you may like to use it:

# Less manual editing of commands. Instead of having to remember to add the correct options to the cmake command line or configure command, you can setup the options once and then kdesrc-build will use your settings from then on, saving you from wasting time because you forgot to enable a setting.
# Command logging to help debug build failures. kdesrc-build logs all command outputs to a file. This has several advantages:
## When a module fails to build, you already have the error output saved to disk, ready to be viewed and compared with other error messages to aid debugging.
## Quieter output. Even with CMake, the output of Qt or a KDE SC module build can be extensive. kdesrc-build does not show the details of a module build (but will show the progress), instead an overview of the build process is displayed.
# It's just easier. Instead of having to learn how to use the Subversion and git tools, and how to setup a KDE build system, you can specify what modules you want build, where to install them to, and any other options you want and then have kdesrc-build actually do it, even while you're away from the computer or busy doing other things.
# It's easy to step in yourself. kdesrc-build uses a standard source and build directory layout, and calls the same commands you would. So kdesrc-build will not interfere with you performing the build or editing the source yourself if you so choose.

=== Setting up ===

==== Prerequisites ====
kdesrc-build is fairly easy to install and setup, but you also need to have the right software installed to build KDE. The requirements to build KDE are available as follows:

* KDE 4: [[../Requirements|KDE 4 Requirements]]

kdesrc-build requires Perl 5.8 or higher. It is installed by default with most distributions, and is included in the link above. Check your version of Perl with:
<syntaxhighlight lang="text">perl -v</syntaxhighlight>

You will also need [https://github.com/gisle/libwww-perl#readme libwww], a collection of Perl Internet-related modules.

{{note|kdesrc-build is developed on a Linux system, but it should work on the various BSD distributions as well (although GNU tools may be required).}}

==== Download and install kdesrc-build ====
Once your system is setup to be able to compile the KDE SC, you can download kdesrc-build from its website, [http://kdesrc-build.kde.org/ kdesrc-build.kde.org]. The file you download will contain (at least) the kdesrc-build script and a sample configuration file. Installing kdesrc-build is as simple as saving the file and making it executable. If you'd like, you can move it to a directory in your PATH, however for this example we'll put it into the KDE source directory that we use (~/kdesrc)

<syntaxhighlight lang="bash">
mkdir -p ~/kdesrc &&
cd ~/kdesrc &&
tar xjvf ~/path/to/kdesrc-build-1.14.tar.bz2 &&
cp kdesrc-build-1.14/kdesrc-build .
</syntaxhighlight>

Alternatively, the newest kdesrc-build script (and sample config file) can be pulled directly from git:
<syntaxhighlight lang="bash">
git clone git://anongit.kde.org/kdesrc-build.git ~/kdesrc
</syntaxhighlight>

==== Setup the configuration ====
Now you should [[Getting Started/Build/kdesrc-buildrc|setup your configuration]]. For the most part the defaults in the included kdesrc-buildrc-sample should be sufficient.

<syntaxhighlight lang="bash">
cp ~/kdesrc/kdesrc-build-1.14.1/kdesrc-buildrc-sample ~/.kdesrc-buildrc
# Now edit the ~/.kdesrc-buildrc
</syntaxhighlight>

{{tip|Note that the config file's name begins with a leading ., making it a hidden file. You may need to show hidden files in Dolphin or Konqueror to find the configuration file to edit it. Or, you can edit the sample before copying it to ~/.kdesrc-buildrc.}}

Also, make sure that the modules you'll want to build are included. You'll want the following at the least:

* qt-copy, kdesupport, kdelibs, kdepimlibs, kdebase

Modules are built in the order they appear in your ~/.kdesrc-buildrc, so the first module should be qt-copy, kdelibs should be before any other KDE SC module, and so on.

{{note|The sample configuration file does include these modules by default, you won't need to make many changes unless you'd like to add some modules to the build by uncommenting them.}}

You may want to enable the make-install-prefix option if you are installing KDE SC or Qt to a directory that is not in your home directory. make-install-prefix allows you to run su or sudo during the make install process so you can install files as root, or set certain programs to execute with higher permissions (This is required for certain programs to execute properly).

<pre>module kdelibs
make-install-prefix sudo -S # sudo with no stdin
end module

module kdebase
make-install-prefix sudo -S
end module</pre>

If a module you'd like to build isn't already present, simply add

<pre>module <module-name>
end module</pre> at the end of the ~/.kdesrc-buildrc. <module-name> would be whatever the module is called in the software repository (for instance, kdemultimedia).

===== Git-based modules =====

Some KDE projects use the "git" source-control software instead of Subversion (as part of an ongoing migration to git). This includes software like Amarok and Konversation.

To build these modules in kdesrc-build, you just need to add a couple of lines to the module configuration. For example, konversation is developed in the Git repository at [https://projects.kde.org/projects/extragear/network/konversation/repository]. So you would just add a module (you can pick whatever name for the module you like, as long as it's not already used):

<pre>module konversation
repository git://anongit.kde.org/konversation
branch master
end module</pre>

In this case I selected the "master" branch since that is the default git branch.

Now whenever you build konversation, kdesrc-build will use git instead of Subversion.

==== Useful kdesrc-build commands ====
kdesrc-build is driven from the command line, so here's a guide to some of the more useful command line options:

<table cellpadding="2">
<tr>
<th>Option</th><th>Effect</th>
</tr>
<tr>
<td><tt><span style="white-space:nowrap;">[http://kdesrc-build.kde.org/documentation/cmdline.html#cmdline-pretend --pretend]</span></tt> (Short form <tt><span style="white-space:nowrap;">-p</span></tt>)</td>
<td>This option is like a dry run. kdesrc-build will process the options and its configuration like normal, and run through the build as normal, but instead of downloading or running the build will instead output what kdesrc-build would have done. You should always run with -p before running kdesrc-build to make sure it is doing what you expect.</td>
</tr>
<tr>
<td><tt>[http://kdesrc-build.kde.org/documentation/cmdline.html#cmdline-no-svn --no-svn]</tt> (Alt. form <tt>--no-src</tt>)</td><td>This option skips the source code update step. This is useful if you're running kdesrc-build again soon after the last update and don't want to wait to find out there were no changes.</td>
</tr>
<tr>
<td><tt>[http://kdesrc-build.kde.org/documentation/cmdline.html#cmdline-refresh-build --refresh-build]</tt></td><td>This option causes kdesrc-build to delete the current build information for the given modules and start building them again from scratch. This option takes a lot of time but gives the best chance of a successful build.</td>
</tr>
</table>

Any other non-option arguments on the command line are assumed to be modules to build (and are built in the order provided on the command line). If no modules are specified, all of the modules listed in the ~/.kdesrc-buildrc are built in the order listed in the file.

== Build ==
We're almost there. If you're happy with your settings then it's time to test out kdesrc-build. In theory things are as simple as running kdesrc-build and then coming back later. ;)

<syntaxhighlight lang="bash">
cd ~/kdesrc
./kdesrc-build
</syntaxhighlight>

You may want to test by building qt-copy first however.

<syntaxhighlight lang="bash">
cd ~/kdesrc
./kdesrc-build qt-copy
</syntaxhighlight>

{{tip|If you have the [http://www.gnu.org/software/screen/ GNU screen] program available then you should definitely use it to run kdesrc-build, as you can detach your kdesrc-build session and logout while kdesrc-build is still running.}}

If the build failed (kdesrc-build will error out with a nice bright red error message) then there are several possibilities:

# You are missing a key piece of required software (such as a development library)
# The KDE SC code being compiled is broken in some fashion to where it won't build. This is commonly due to newly committed code that worked on the developer's machine, or occasionally on Mondays (when incompatible changes are permitted to kdelibs).
# kdesrc-build is not setup properly. You may be trying to install to a directory that you have no permissions to access for instance, or you may have specified a system qtdir that does not exist.
# The module may depend on a newer version of qt-copy or kdelibs (or other module). In this case you'll have to run kdesrc-build to update the out-of-date module first.

How do you find out what the error was? The output of the failing command will be in the log directory. By default, all log output is in the {{path|log}} subdirectory of the KDE SC source directory. The log directory is laid out like this: {{path|log/date-run/module/output-file.log}}. To simplify finding the appropriate file, there are a couple of symlinks created:

{{path|log/latest}} always has the debugging output for the last time kdesrc-build was run (--pretend doesn't count toward this)
{{path|log/latest/<module>/error.log}} has the debugging output for the command that caused a module build to fail.

For instance if qt-copy just failed to build you could read the output like this:

<syntaxhighlight lang="bash">
cd ~/kderc
kwrite log/latest/qt-copy/error.log
</syntaxhighlight>

Replace kwrite with your preferred editor. Hopefully the output can guide you to resolving the problem. For instance, if the failure is a cmake output saying you're missing a library, install that library and try again. ;) For link errors you can try running a --refresh-build on the module (or if that doesn't work, required libraries like qt-copy and kdelibs).

If you're stumped by the error you may want to wait a day and try updating again, and hope that the reason for the error has been fixed. You can also try mailing the [http://www.kde.org/mailinglists/ kde-devel] mailing list to see if others know about the problem or have had similar issues.

== Running KDE ==

Assuming you got enough of the modules to build and install to have a working KDE installation, you'll still need to setup your environment correctly to run it. kdesrc-build doesn't help you out here (yet), so you should follow the instructions [[Getting_Started/Using_an_IDE_with_KDE4|here]].

Make sure to use the same paths as the ones you defined in .kdesrc-buildrc: for the KDEDIRS and KDEDIR variable use the setting of the "prefix" option (in the global section). For the QTDIR variable use the setting of the "qtdir" option.

== Keeping KDE up to date ==

Keeping your KDE installation up to date is as simple as running kdesrc-build again. Every kdesrc-build has these phases:

# Update the source code for all modules being built.
# Build and then install all the modules.

Old build directories are not deleted by default, so the build after a small update will not normally take as long as the initial build of a module. This is called "incremental make". However it may be necessary at times to perform a full rebuild due to inconsistencies between the build directory configuation and changes to the source directory. You can use the --refresh-build option to force a full rebuild.

For more information on how to take advantage of kdesrc-build, see the [http://kdesrc-build.kde.org/documentation online documentation] for kdesrc-build, which describes all of the module options and command line options available for kdesrc-build and gives tips on how to perform various useful tasks.

If you have any questions that are not answered please feel free to add them under the Discussion entry for this page and hopefully someone will be able to get the answer.

= See also =
* To browse the KDE Subversion repository, use [http://websvn.kde.org/trunk/KDE WebSVN].
* To browse any of the various KDE projects using git, you can go to [http://projects.kde.org KDE Git Projects] or to [http://gitweb.kde.org KDE Git Web].
* The Nokia Qt toolkit used by KDE can be browsed at [http://qt.gitorious.org/qt Nokia's Qt version on gitorious].

[[Category:Build_KDE]]
[[Category:Tutorial]]

Getting Started/Build/kdesrc-build

2012-02-11T16:31:19Z

Tstaerk: /* Setup the configuration */

{{Template:I18n/Language Navigation Bar|Getting_Started/Build/kdesrc-build}}

{{note|It is possible to build KDE 3 using older versions of kdesrc-build, but this is not described here.}}

== Building KDE using the kdesrc-build tool ==

=== Introduction to kdesrc-build ===

[http://kdesrc-build.kde.org/ kdesrc-build] (formerly kdesvn-build) is a tool to allow users and developers to easily download and build the latest versions of the KDE Software Compilation (KDE SC) from the KDE source code repositories. It automates the following tasks and more:

* Performing the initial checkout.
* Handling updates for modules that are already checked out.
* Setting up the build system for the module.
* Performing the build and install.
* Specifying your CMake options or configure flags (so you don't have to remember them every time).
* Logging build errors so you can review them easier for troubleshooting.

It is not the end-all for your troubles building KDE, [[../Troubleshooting|Troubleshooting]] still applies. Many errors that occur using other methods occur here too, you read the log files that are stored for you.

=== Why use kdesrc-build? ===

So why use kdesrc-build? There are several reasons you may like to use it:

# Less manual editing of commands. Instead of having to remember to add the correct options to the cmake command line or configure command, you can setup the options once and then kdesrc-build will use your settings from then on, saving you from wasting time because you forgot to enable a setting.
# Command logging to help debug build failures. kdesrc-build logs all command outputs to a file. This has several advantages:
## When a module fails to build, you already have the error output saved to disk, ready to be viewed and compared with other error messages to aid debugging.
## Quieter output. Even with CMake, the output of Qt or a KDE SC module build can be extensive. kdesrc-build does not show the details of a module build (but will show the progress), instead an overview of the build process is displayed.
# It's just easier. Instead of having to learn how to use the Subversion and git tools, and how to setup a KDE build system, you can specify what modules you want build, where to install them to, and any other options you want and then have kdesrc-build actually do it, even while you're away from the computer or busy doing other things.
# It's easy to step in yourself. kdesrc-build uses a standard source and build directory layout, and calls the same commands you would. So kdesrc-build will not interfere with you performing the build or editing the source yourself if you so choose.

=== Setting up ===

==== Prerequisites ====
kdesrc-build is fairly easy to install and setup, but you also need to have the right software installed to build KDE. The requirements to build KDE are available as follows:

* KDE 4: [[../Requirements|KDE 4 Requirements]]

kdesrc-build requires Perl 5.8 or higher. It is installed by default with most distributions, and is included in the link above. Check your version of Perl with:
<syntaxhighlight lang="text">perl -v</syntaxhighlight>

You will also need [https://github.com/gisle/libwww-perl#readme libwww], a collection of Perl Internet-related modules.

{{note|kdesrc-build is developed on a Linux system, but it should work on the various BSD distributions as well (although GNU tools may be required).}}

==== Download and install kdesrc-build ====
Once your system is setup to be able to compile the KDE SC, you can download kdesrc-build from its website, [http://kdesrc-build.kde.org/ kdesrc-build.kde.org]. The file you download will contain (at least) the kdesrc-build script and a sample configuration file. Installing kdesrc-build is as simple as saving the file and making it executable. If you'd like, you can move it to a directory in your PATH, however for this example we'll put it into the KDE source directory that we use (~/kdesrc)

<syntaxhighlight lang="bash">
mkdir -p ~/kdesrc &&
cd ~/kdesrc &&
tar xjvf ~/path/to/kdesrc-build-1.14.tar.bz2 &&
cp kdesrc-build-1.14/kdesrc-build .
</syntaxhighlight>

Alternatively, the newest kdesrc-build script (and sample config file) can be pulled directly from git:
<syntaxhighlight lang="bash">
git clone git://anongit.kde.org/kdesrc-build.git ~/kdesrc
</syntaxhighlight>

==== Setup the configuration ====
Now you should [[Getting Started/Build/kdesrc-buildrc|setup your configuration]]. For the most part the defaults in the included kdesrc-buildrc-sample should be sufficient.

<syntaxhighlight lang="bash">
cp ~/kdesrc/kdesrc-build-1.14/kdesrc-buildrc-sample ~/.kdesrc-buildrc
# Now edit the ~/.kdesrc-buildrc
</syntaxhighlight>

{{tip|Note that the config file's name begins with a leading ., making it a hidden file. You may need to show hidden files in Dolphin or Konqueror to find the configuration file to edit it. Or, you can edit the sample before copying it to ~/.kdesrc-buildrc.}}

Also, make sure that the modules you'll want to build are included. You'll want the following at the least:

* qt-copy, kdesupport, kdelibs, kdepimlibs, kdebase

Modules are built in the order they appear in your ~/.kdesrc-buildrc, so the first module should be qt-copy, kdelibs should be before any other KDE SC module, and so on.

{{note|The sample configuration file does include these modules by default, you won't need to make many changes unless you'd like to add some modules to the build by uncommenting them.}}

You may want to enable the make-install-prefix option if you are installing KDE SC or Qt to a directory that is not in your home directory. make-install-prefix allows you to run su or sudo during the make install process so you can install files as root, or set certain programs to execute with higher permissions (This is required for certain programs to execute properly).

<pre>module kdelibs
make-install-prefix sudo -S # sudo with no stdin
end module

module kdebase
make-install-prefix sudo -S
end module</pre>

If a module you'd like to build isn't already present, simply add

<pre>module <module-name>
end module</pre> at the end of the ~/.kdesrc-buildrc. <module-name> would be whatever the module is called in the software repository (for instance, kdemultimedia).

===== Git-based modules =====

Some KDE projects use the "git" source-control software instead of Subversion (as part of an ongoing migration to git). This includes software like Amarok and Konversation.

To build these modules in kdesrc-build, you just need to add a couple of lines to the module configuration. For example, konversation is developed in the Git repository at [https://projects.kde.org/projects/extragear/network/konversation/repository]. So you would just add a module (you can pick whatever name for the module you like, as long as it's not already used):

<pre>module konversation
repository git://anongit.kde.org/konversation
branch master
end module</pre>

In this case I selected the "master" branch since that is the default git branch.

Now whenever you build konversation, kdesrc-build will use git instead of Subversion.

==== Useful kdesrc-build commands ====
kdesrc-build is driven from the command line, so here's a guide to some of the more useful command line options:

<table cellpadding="2">
<tr>
<th>Option</th><th>Effect</th>
</tr>
<tr>
<td><tt><span style="white-space:nowrap;">[http://kdesrc-build.kde.org/documentation/cmdline.html#cmdline-pretend --pretend]</span></tt> (Short form <tt><span style="white-space:nowrap;">-p</span></tt>)</td>
<td>This option is like a dry run. kdesrc-build will process the options and its configuration like normal, and run through the build as normal, but instead of downloading or running the build will instead output what kdesrc-build would have done. You should always run with -p before running kdesrc-build to make sure it is doing what you expect.</td>
</tr>
<tr>
<td><tt>[http://kdesrc-build.kde.org/documentation/cmdline.html#cmdline-no-svn --no-svn]</tt> (Alt. form <tt>--no-src</tt>)</td><td>This option skips the source code update step. This is useful if you're running kdesrc-build again soon after the last update and don't want to wait to find out there were no changes.</td>
</tr>
<tr>
<td><tt>[http://kdesrc-build.kde.org/documentation/cmdline.html#cmdline-refresh-build --refresh-build]</tt></td><td>This option causes kdesrc-build to delete the current build information for the given modules and start building them again from scratch. This option takes a lot of time but gives the best chance of a successful build.</td>
</tr>
</table>

Any other non-option arguments on the command line are assumed to be modules to build (and are built in the order provided on the command line). If no modules are specified, all of the modules listed in the ~/.kdesrc-buildrc are built in the order listed in the file.

== Build ==
We're almost there. If you're happy with your settings then it's time to test out kdesrc-build. In theory things are as simple as running kdesrc-build and then coming back later. ;)

<syntaxhighlight lang="bash">
cd ~/kdesrc
./kdesrc-build
</syntaxhighlight>

You may want to test by building qt-copy first however.

<syntaxhighlight lang="bash">
cd ~/kdesrc
./kdesrc-build qt-copy
</syntaxhighlight>

{{tip|If you have the [http://www.gnu.org/software/screen/ GNU screen] program available then you should definitely use it to run kdesrc-build, as you can detach your kdesrc-build session and logout while kdesrc-build is still running.}}

If the build failed (kdesrc-build will error out with a nice bright red error message) then there are several possibilities:

# You are missing a key piece of required software (such as a development library)
# The KDE SC code being compiled is broken in some fashion to where it won't build. This is commonly due to newly committed code that worked on the developer's machine, or occasionally on Mondays (when incompatible changes are permitted to kdelibs).
# kdesrc-build is not setup properly. You may be trying to install to a directory that you have no permissions to access for instance, or you may have specified a system qtdir that does not exist.
# The module may depend on a newer version of qt-copy or kdelibs (or other module). In this case you'll have to run kdesrc-build to update the out-of-date module first.

How do you find out what the error was? The output of the failing command will be in the log directory. By default, all log output is in the {{path|log}} subdirectory of the KDE SC source directory. The log directory is laid out like this: {{path|log/date-run/module/output-file.log}}. To simplify finding the appropriate file, there are a couple of symlinks created:

{{path|log/latest}} always has the debugging output for the last time kdesrc-build was run (--pretend doesn't count toward this)
{{path|log/latest/<module>/error.log}} has the debugging output for the command that caused a module build to fail.

For instance if qt-copy just failed to build you could read the output like this:

<syntaxhighlight lang="bash">
cd ~/kderc
kwrite log/latest/qt-copy/error.log
</syntaxhighlight>

Replace kwrite with your preferred editor. Hopefully the output can guide you to resolving the problem. For instance, if the failure is a cmake output saying you're missing a library, install that library and try again. ;) For link errors you can try running a --refresh-build on the module (or if that doesn't work, required libraries like qt-copy and kdelibs).

If you're stumped by the error you may want to wait a day and try updating again, and hope that the reason for the error has been fixed. You can also try mailing the [http://www.kde.org/mailinglists/ kde-devel] mailing list to see if others know about the problem or have had similar issues.

== Running KDE ==

Assuming you got enough of the modules to build and install to have a working KDE installation, you'll still need to setup your environment correctly to run it. kdesrc-build doesn't help you out here (yet), so you should follow the instructions [[Getting_Started/Using_an_IDE_with_KDE4|here]].

Make sure to use the same paths as the ones you defined in .kdesrc-buildrc: for the KDEDIRS and KDEDIR variable use the setting of the "prefix" option (in the global section). For the QTDIR variable use the setting of the "qtdir" option.

== Keeping KDE up to date ==

Keeping your KDE installation up to date is as simple as running kdesrc-build again. Every kdesrc-build has these phases:

# Update the source code for all modules being built.
# Build and then install all the modules.

Old build directories are not deleted by default, so the build after a small update will not normally take as long as the initial build of a module. This is called "incremental make". However it may be necessary at times to perform a full rebuild due to inconsistencies between the build directory configuation and changes to the source directory. You can use the --refresh-build option to force a full rebuild.

For more information on how to take advantage of kdesrc-build, see the [http://kdesrc-build.kde.org/documentation online documentation] for kdesrc-build, which describes all of the module options and command line options available for kdesrc-build and gives tips on how to perform various useful tasks.

If you have any questions that are not answered please feel free to add them under the Discussion entry for this page and hopefully someone will be able to get the answer.

= See also =
* To browse the KDE Subversion repository, use [http://websvn.kde.org/trunk/KDE WebSVN].
* To browse any of the various KDE projects using git, you can go to [http://projects.kde.org KDE Git Projects] or to [http://gitweb.kde.org KDE Git Web].
* The Nokia Qt toolkit used by KDE can be browsed at [http://qt.gitorious.org/qt Nokia's Qt version on gitorious].

[[Category:Build_KDE]]
[[Category:Tutorial]]

Getting Started/Build/kdesrc-build

2012-02-11T16:30:54Z

Tstaerk: /* Download and install kdesrc-build */

{{Template:I18n/Language Navigation Bar|Getting_Started/Build/kdesrc-build}}

{{note|It is possible to build KDE 3 using older versions of kdesrc-build, but this is not described here.}}

== Building KDE using the kdesrc-build tool ==

=== Introduction to kdesrc-build ===

[http://kdesrc-build.kde.org/ kdesrc-build] (formerly kdesvn-build) is a tool to allow users and developers to easily download and build the latest versions of the KDE Software Compilation (KDE SC) from the KDE source code repositories. It automates the following tasks and more:

* Performing the initial checkout.
* Handling updates for modules that are already checked out.
* Setting up the build system for the module.
* Performing the build and install.
* Specifying your CMake options or configure flags (so you don't have to remember them every time).
* Logging build errors so you can review them easier for troubleshooting.

It is not the end-all for your troubles building KDE, [[../Troubleshooting|Troubleshooting]] still applies. Many errors that occur using other methods occur here too, you read the log files that are stored for you.

=== Why use kdesrc-build? ===

So why use kdesrc-build? There are several reasons you may like to use it:

# Less manual editing of commands. Instead of having to remember to add the correct options to the cmake command line or configure command, you can setup the options once and then kdesrc-build will use your settings from then on, saving you from wasting time because you forgot to enable a setting.
# Command logging to help debug build failures. kdesrc-build logs all command outputs to a file. This has several advantages:
## When a module fails to build, you already have the error output saved to disk, ready to be viewed and compared with other error messages to aid debugging.
## Quieter output. Even with CMake, the output of Qt or a KDE SC module build can be extensive. kdesrc-build does not show the details of a module build (but will show the progress), instead an overview of the build process is displayed.
# It's just easier. Instead of having to learn how to use the Subversion and git tools, and how to setup a KDE build system, you can specify what modules you want build, where to install them to, and any other options you want and then have kdesrc-build actually do it, even while you're away from the computer or busy doing other things.
# It's easy to step in yourself. kdesrc-build uses a standard source and build directory layout, and calls the same commands you would. So kdesrc-build will not interfere with you performing the build or editing the source yourself if you so choose.

=== Setting up ===

==== Prerequisites ====
kdesrc-build is fairly easy to install and setup, but you also need to have the right software installed to build KDE. The requirements to build KDE are available as follows:

* KDE 4: [[../Requirements|KDE 4 Requirements]]

kdesrc-build requires Perl 5.8 or higher. It is installed by default with most distributions, and is included in the link above. Check your version of Perl with:
<syntaxhighlight lang="text">perl -v</syntaxhighlight>

You will also need [https://github.com/gisle/libwww-perl#readme libwww], a collection of Perl Internet-related modules.

{{note|kdesrc-build is developed on a Linux system, but it should work on the various BSD distributions as well (although GNU tools may be required).}}

==== Download and install kdesrc-build ====
Once your system is setup to be able to compile the KDE SC, you can download kdesrc-build from its website, [http://kdesrc-build.kde.org/ kdesrc-build.kde.org]. The file you download will contain (at least) the kdesrc-build script and a sample configuration file. Installing kdesrc-build is as simple as saving the file and making it executable. If you'd like, you can move it to a directory in your PATH, however for this example we'll put it into the KDE source directory that we use (~/kdesrc)

<syntaxhighlight lang="bash">
mkdir -p ~/kdesrc &&
cd ~/kdesrc &&
tar xjvf ~/path/to/kdesrc-build-1.14.tar.bz2 &&
cp kdesrc-build-1.14/kdesrc-build .
</syntaxhighlight>

Alternatively, the newest kdesrc-build script (and sample config file) can be pulled directly from git:
<syntaxhighlight lang="bash">
git clone git://anongit.kde.org/kdesrc-build.git ~/kdesrc
</syntaxhighlight>

==== Setup the configuration ====
Now you should [[Getting Started/Build/kdesrc-buildrc|setup your configuration]]. For the most part the defaults in the included kdesrc-buildrc-sample should be sufficient.

<syntaxhighlight lang="bash">
cp ~/kdesrc/kdesrc-build-1.12/kdesrc-buildrc-sample ~/.kdesrc-buildrc
# Now edit the ~/.kdesrc-buildrc
</syntaxhighlight>

{{tip|Note that the config file's name begins with a leading ., making it a hidden file. You may need to show hidden files in Dolphin or Konqueror to find the configuration file to edit it. Or, you can edit the sample before copying it to ~/.kdesrc-buildrc.}}

Also, make sure that the modules you'll want to build are included. You'll want the following at the least:

* qt-copy, kdesupport, kdelibs, kdepimlibs, kdebase

Modules are built in the order they appear in your ~/.kdesrc-buildrc, so the first module should be qt-copy, kdelibs should be before any other KDE SC module, and so on.

{{note|The sample configuration file does include these modules by default, you won't need to make many changes unless you'd like to add some modules to the build by uncommenting them.}}

You may want to enable the make-install-prefix option if you are installing KDE SC or Qt to a directory that is not in your home directory. make-install-prefix allows you to run su or sudo during the make install process so you can install files as root, or set certain programs to execute with higher permissions (This is required for certain programs to execute properly).

<pre>module kdelibs
make-install-prefix sudo -S # sudo with no stdin
end module

module kdebase
make-install-prefix sudo -S
end module</pre>

If a module you'd like to build isn't already present, simply add

<pre>module <module-name>
end module</pre> at the end of the ~/.kdesrc-buildrc. <module-name> would be whatever the module is called in the software repository (for instance, kdemultimedia).

===== Git-based modules =====

Some KDE projects use the "git" source-control software instead of Subversion (as part of an ongoing migration to git). This includes software like Amarok and Konversation.

To build these modules in kdesrc-build, you just need to add a couple of lines to the module configuration. For example, konversation is developed in the Git repository at [https://projects.kde.org/projects/extragear/network/konversation/repository]. So you would just add a module (you can pick whatever name for the module you like, as long as it's not already used):

<pre>module konversation
repository git://anongit.kde.org/konversation
branch master
end module</pre>

In this case I selected the "master" branch since that is the default git branch.

Now whenever you build konversation, kdesrc-build will use git instead of Subversion.

==== Useful kdesrc-build commands ====
kdesrc-build is driven from the command line, so here's a guide to some of the more useful command line options:

<table cellpadding="2">
<tr>
<th>Option</th><th>Effect</th>
</tr>
<tr>
<td><tt><span style="white-space:nowrap;">[http://kdesrc-build.kde.org/documentation/cmdline.html#cmdline-pretend --pretend]</span></tt> (Short form <tt><span style="white-space:nowrap;">-p</span></tt>)</td>
<td>This option is like a dry run. kdesrc-build will process the options and its configuration like normal, and run through the build as normal, but instead of downloading or running the build will instead output what kdesrc-build would have done. You should always run with -p before running kdesrc-build to make sure it is doing what you expect.</td>
</tr>
<tr>
<td><tt>[http://kdesrc-build.kde.org/documentation/cmdline.html#cmdline-no-svn --no-svn]</tt> (Alt. form <tt>--no-src</tt>)</td><td>This option skips the source code update step. This is useful if you're running kdesrc-build again soon after the last update and don't want to wait to find out there were no changes.</td>
</tr>
<tr>
<td><tt>[http://kdesrc-build.kde.org/documentation/cmdline.html#cmdline-refresh-build --refresh-build]</tt></td><td>This option causes kdesrc-build to delete the current build information for the given modules and start building them again from scratch. This option takes a lot of time but gives the best chance of a successful build.</td>
</tr>
</table>

Any other non-option arguments on the command line are assumed to be modules to build (and are built in the order provided on the command line). If no modules are specified, all of the modules listed in the ~/.kdesrc-buildrc are built in the order listed in the file.

== Build ==
We're almost there. If you're happy with your settings then it's time to test out kdesrc-build. In theory things are as simple as running kdesrc-build and then coming back later. ;)

<syntaxhighlight lang="bash">
cd ~/kdesrc
./kdesrc-build
</syntaxhighlight>

You may want to test by building qt-copy first however.

<syntaxhighlight lang="bash">
cd ~/kdesrc
./kdesrc-build qt-copy
</syntaxhighlight>

{{tip|If you have the [http://www.gnu.org/software/screen/ GNU screen] program available then you should definitely use it to run kdesrc-build, as you can detach your kdesrc-build session and logout while kdesrc-build is still running.}}

If the build failed (kdesrc-build will error out with a nice bright red error message) then there are several possibilities:

# You are missing a key piece of required software (such as a development library)
# The KDE SC code being compiled is broken in some fashion to where it won't build. This is commonly due to newly committed code that worked on the developer's machine, or occasionally on Mondays (when incompatible changes are permitted to kdelibs).
# kdesrc-build is not setup properly. You may be trying to install to a directory that you have no permissions to access for instance, or you may have specified a system qtdir that does not exist.
# The module may depend on a newer version of qt-copy or kdelibs (or other module). In this case you'll have to run kdesrc-build to update the out-of-date module first.

How do you find out what the error was? The output of the failing command will be in the log directory. By default, all log output is in the {{path|log}} subdirectory of the KDE SC source directory. The log directory is laid out like this: {{path|log/date-run/module/output-file.log}}. To simplify finding the appropriate file, there are a couple of symlinks created:

{{path|log/latest}} always has the debugging output for the last time kdesrc-build was run (--pretend doesn't count toward this)
{{path|log/latest/<module>/error.log}} has the debugging output for the command that caused a module build to fail.

For instance if qt-copy just failed to build you could read the output like this:

<syntaxhighlight lang="bash">
cd ~/kderc
kwrite log/latest/qt-copy/error.log
</syntaxhighlight>

Replace kwrite with your preferred editor. Hopefully the output can guide you to resolving the problem. For instance, if the failure is a cmake output saying you're missing a library, install that library and try again. ;) For link errors you can try running a --refresh-build on the module (or if that doesn't work, required libraries like qt-copy and kdelibs).

If you're stumped by the error you may want to wait a day and try updating again, and hope that the reason for the error has been fixed. You can also try mailing the [http://www.kde.org/mailinglists/ kde-devel] mailing list to see if others know about the problem or have had similar issues.

== Running KDE ==

Assuming you got enough of the modules to build and install to have a working KDE installation, you'll still need to setup your environment correctly to run it. kdesrc-build doesn't help you out here (yet), so you should follow the instructions [[Getting_Started/Using_an_IDE_with_KDE4|here]].

Make sure to use the same paths as the ones you defined in .kdesrc-buildrc: for the KDEDIRS and KDEDIR variable use the setting of the "prefix" option (in the global section). For the QTDIR variable use the setting of the "qtdir" option.

== Keeping KDE up to date ==

Keeping your KDE installation up to date is as simple as running kdesrc-build again. Every kdesrc-build has these phases:

# Update the source code for all modules being built.
# Build and then install all the modules.

Old build directories are not deleted by default, so the build after a small update will not normally take as long as the initial build of a module. This is called "incremental make". However it may be necessary at times to perform a full rebuild due to inconsistencies between the build directory configuation and changes to the source directory. You can use the --refresh-build option to force a full rebuild.

For more information on how to take advantage of kdesrc-build, see the [http://kdesrc-build.kde.org/documentation online documentation] for kdesrc-build, which describes all of the module options and command line options available for kdesrc-build and gives tips on how to perform various useful tasks.

If you have any questions that are not answered please feel free to add them under the Discussion entry for this page and hopefully someone will be able to get the answer.

= See also =
* To browse the KDE Subversion repository, use [http://websvn.kde.org/trunk/KDE WebSVN].
* To browse any of the various KDE projects using git, you can go to [http://projects.kde.org KDE Git Projects] or to [http://gitweb.kde.org KDE Git Web].
* The Nokia Qt toolkit used by KDE can be browsed at [http://qt.gitorious.org/qt Nokia's Qt version on gitorious].

[[Category:Build_KDE]]
[[Category:Tutorial]]