This forum has been archived. All content is frozen. Please use KDE Discuss instead.

Help resolving KDE build issues...

Tags: None
(comma "," separated)
andre_orwell
Registered Member
Posts
181
Karma
1

Help resolving KDE build issues...

Sat Nov 01, 2008 1:49 am
Hi,

I've been slowly piecing together a sufficiently complete development environment. But I have a few issues. Is this the right place to ask for help? For reference I am using ubuntu/kubuntu 8.10 and have followed the instructions in techbase.

building qt-copy:
I can build this fine but the configuration tells me that it is not including phonon support (no gstreamer)... I have installed the gstreamer-dev packages as far as I can tell. Any suggestions?

building kdesupport:
Apparanetly I have no backends for soprano... there is a selection I can install but I have heard that some are very slow and there is a "preferred" backend. Which is it and how best should I install it?
The install step also included the ominous words:
Code: Select all
Note that '/home/kdev/kde/share' is not in the search path
set by the XDG_DATA_HOME and XDG_DATA_DIRS               
environment variables, so applications may not           
be able to find it until you set them. The               
directories currently searched are:

but no directories follow. I'm not sure what this means, if I need to fix it or how I would fix it.

Also. I have been using the command cmakekde to build packages. Can I use it to do a rebuild or a clean?

Thanks for any tips and apologies if these are "well known". I'm just new to developing for KDE and there seems to be a large barrier in the initial setup.


andre_orwell, :-[
User avatar
YeahReally
Registered Member
Posts
71
Karma
1
OS
andre_orwell wrote:Hi,

Hi
I've been slowly piecing together a sufficiently complete development environment. But I have a few issues. Is this the right place to ask for help? For reference I am using ubuntu/kubuntu 8.10 and have followed the instructions in techbase.

building qt-copy:
I can build this fine but the configuration tells me that it is not including phonon support (no gstreamer)... I have installed the gstreamer-dev packages as far as I can tell. Any suggestions?

I do not know this. I use the packaged binaries. Maybe you have to pass an option to ./configure?

Debian uses the following libraries to build phonon (should be similar to kubuntu):
automoc, libglu1-mesa-dev, libqt4-opengl-dev, libxml2-dev, libglib2.0-dev, libgstreamer0.10-dev, libgstreamer-plugins-base0.10-dev, libasound2-dev
building kdesupport:
Apparanetly I have no backends for soprano... there is a selection I can install but I have heard that some are very slow and there is a "preferred" backend. Which is it and how best should I install it?

It depends. There is redland which is C++, but slower than Sesame2, written in Java. The latter is not available in Debian (and is Java) so I do not use it.
The install step also included the ominous words:
Code: Select all
Note that '/home/kdev/kde/share' is not in the search path
set by the XDG_DATA_HOME and XDG_DATA_DIRS               
environment variables, so applications may not           
be able to find it until you set them. The               
directories currently searched are:

but no directories follow. I'm not sure what this means, if I need to fix it or how I would fix it.

I get that too. No problems so far.
Also. I have been using the command cmakekde to build packages. Can I use it to do a rebuild or a clean?

You can reuse it to update your installation once you «svn update».
Thanks for any tips and apologies if these are "well known". I'm just new to developing for KDE and there seems to be a large barrier in the initial setup.


Debian GNU/Linux Lenny
KDE 4.1.96

How many bugs have you triaged today?
andre_orwell
Registered Member
Posts
181
Karma
1
[quote='YeahReally' pid='13054' dateline='1225505536']
Debian uses the following libraries to build phonon (should be similar to kubuntu):
automoc, libglu1-mesa-dev, libqt4-opengl-dev, libxml2-dev, libglib2.0-dev, libgstreamer0.10-dev, libgstreamer-plugins-base0.10-dev, libasound2-dev
[quote]

Thanks... the only one I am missing from that set is libgstreamer-plugins-base0.10-dev

installed...

I am configuring using
Code: Select all
./configure -qt-gif -debug -fast -no-separate-debug-info -system-libpng -system-libjpeg -system-zlib -dbus -webkit -nomake examples -nomake demos -prefix $QTDIR


which (finally) seems to configure for a qt install which is only missing NAS sound and webkit in assistant. Gstreamer is found!

Thanks... progressing through the rest of your post. :-)


... a little later...
I feel the same about soprano backends so will not worry about that for now.

my main issue with building using cmakekde was how to handle updates to configuration (such as when I add new dev packages to my base system or rebuilding qt-copy). For the moment I have been deleting the build folder to force a rebuild but I'm sure there is a better way if this is actually required.

Anyway, progress is happening - thanks again

Last edited by andre_orwell on Sat Nov 01, 2008 7:49 am, edited 1 time in total.


andre_orwell, :-[
User avatar
anda_skoa
KDE Developer
Posts
783
Karma
4
OS
andre_orwell wrote:building qt-copy:
I can build this fine but the configuration tells me that it is not including phonon support (no gstreamer)... I have installed the gstreamer-dev packages as far as I can tell. Any suggestions?


Actually most KDE developer will build qt-copy explicitly without Phonon and use the most recent Phonon from kdesupport instead.

andre_orwell wrote:Apparanetly I have no backends for soprano... there is a selection I can install but I have heard that some are very slow and there is a "preferred" backend. Which is it and how best should I install it?


Unless you are planning to do anything Nepomuk related it might be unimportant which backends you have available as long as all build requirements of the stack above (kdelibs, etc) are sufficiently fullfilled.

This is often especially true for differences regarding performance, since a development setup is most often compiled with lots of debugging information and few or no compiler optimizations, so it will be slow anyway.

andre_orwell wrote:The install step also included the ominous words:
Code: Select all
Note that '/home/kdev/kde/share' is not in the search path
set by the XDG_DATA_HOME and XDG_DATA_DIRS               
environment variables, so applications may not           
be able to find it until you set them. The               
directories currently searched are:

but no directories follow. I'm not sure what this means, if I need to fix it or how I would fix it.


This probably just means that the variables are current unset or empty, in which any program using them will fall back to specified defaults.
In case of XDG_DATA_HOME this will be $HOME/.local/share and in case of XDG_DATA_DIRS it will be /usr/local/share:/usr/share


andre_orwell wrote:Also. I have been using the command cmakekde to build packages. Can I use it to do a rebuild or a clean?


Sorry, no idea. I prefer to do cmake and make for each module individually, which makes it a bit more time consuming but has the nice advantage of allowing me to choose cmake options (especially amount of debug info) per module and on a case-by-case basis.

Cheers,
_


anda_skoa, proud to be a member of KDE forums since 2008-Oct.
User avatar
YeahReally
Registered Member
Posts
71
Karma
1
OS
andre_orwell wrote:my main issue with building using cmakekde was how to handle updates to configuration (such as when I add new dev packages to my base system or rebuilding qt-copy). For the moment I have been deleting the build folder to force a rebuild but I'm sure there is a better way if this is actually required.


You can force a recheck with:
1. Go to build directory
2. «touch CMakeCache.txt»

Next time you «cmakekde» or even «make» it will look what is new in your system.


Debian GNU/Linux Lenny
KDE 4.1.96

How many bugs have you triaged today?
andre_orwell
Registered Member
Posts
181
Karma
1
anda_skoa wrote:Actually most KDE developer will build qt-copy explicitly without Phonon and use the most recent Phonon from kdesupport instead.


Oh... I though phonon was part of Qt

This perhaps explains
why the default build options for qt-copy include -no-phonon

Anyway thanks... eventually I'll get enough deps in place... perhaps next weekend I can actually get into the code...


andre_orwell, :-[
User avatar
anda_skoa
KDE Developer
Posts
783
Karma
4
OS
andre_orwell wrote:
anda_skoa wrote:Actually most KDE developer will build qt-copy explicitly without Phonon and use the most recent Phonon from kdesupport instead.


Oh... I though phonon was part of Qt


It is.
Qt includes a certain version of Phonon, one Qt Software maintains and support for its customers.
The development branch is still in KDE's SVN, in the kdesupport module which holds projects KDE depends on.

You can use either version, though the most recent development version might have additional features and applications depending on those might not be built.

Cheers,
_


anda_skoa, proud to be a member of KDE forums since 2008-Oct.
andre_orwell
Registered Member
Posts
181
Karma
1
Hey I have a build... all the way down through kdepim and koffice.

Is there a typical strategy for debugging apps?
Do most people use kdbg? Do you try and hunt down the relevant code entry point from the console log first? How do you go about debugging a window manager? What actually *is* drkonqi?

How far have I got? Well I can run kde apps in a debugger which is a pretty reasonable start... but its a pretty slow affair so I don't think I'll be single stepping a whole lot of code.

All tips welcome :-)


andre_orwell, :-[
User avatar
anda_skoa
KDE Developer
Posts
783
Karma
4
OS
andre_orwell wrote:Is there a typical strategy for debugging apps?


That totally depends on the problem, the developer's preference and limitations of actions leading to the problem.

andre_orwell wrote:How do you go about debugging a window manager?


Good question. I'd recommend you check if there is a mailing list for KWin development and ask there.

andre_orwell wrote:What actually *is* drkonqi?

That's basically a special crash handler which invokes a separate application to have a user interface for getting information about the crash, e.g. the backtrace.

Cheers,
_


anda_skoa, proud to be a member of KDE forums since 2008-Oct.


Bookmarks



Who is online

Registered users: bartoloni, Bing [Bot], Google [Bot], Sogou [Bot], Yahoo [Bot]