Difference between revisions of "Talk:Installing third party softwares in terminal/Build/KDE4"

Jump to: navigation, search
(Amount of space needed?)
m (Amount of space needed?)
Line 133: Line 133:
== Amount of space needed? ==
== Amount of space needed? ==
It would be nice to know how much space (roughly, in GB) you need for a setup to build and run the basic things and packages.
It would be nice to know how much space (roughly, in GB) you need for a setup to build and run the basic things and packages. --[[User:Liquidat|Liquidat]] 03:08, 7 June 2007 (CEST)

Revision as of 02:08, 7 June 2007


This article is full of errors

For example it *is* nessecary to install qt-copy, even if you keep it in the source directory (which leads to 394583069845 error messages on the console during the install). And kdelibs won't build unless something unknown is done with strigi - if it is installed into KDEDIR, it isn't just found.

This article is complicated

when I wrote this article, it was lean and simple. It has been improved somewhere, but on most places worsened. An example is the directory structure (to get to qt-copy: cd && cd qt-copy; to get to kdelibs: cs && cd kdelibs; to get to kdepim: cs && cd KDE && cd kdepim - no one understands this!!!). Another example is cs and cb which is quite unnecessary as my initial article shows. But of course, with the complexity as the article has NOW, it IS necessary.

Why do you spoil a simple article so that even I no longer find my own subdirs ? --­­­­Tstaerk 10:25, 28 May 2007 (CEST)

Where do you see "cs && cd KDE && cd kdepim"? Because I don't see that anywhere. In any case it would just be "cs kdepim". Perhaps that's the bit need explaining a bit better? --Aseigo 02:48, 29 May 2007 (CEST)
To whom are you talking to? ;) There are many contributors and as it's a wiki an article probably "degenerates" automatically if noone has an eye on it. The article certainly has valuable information and simply needs a cleanup. In other words: Fix it! :) --Dhaumann 12:20, 28 May 2007 (CEST)
IMHO all of this cs/cb/cmakekde and such is only confusing, users just do copy&paste with no really knowledge of what's going on when they type those commands. This way troubleshooting is quite difficult, and they learn nothing about the real compiling way. The concept of source/build dirs is barely noted. The old http://developer.kde.org/build/trunk.html has some more commands to type, but it was quite more understandable and clear about the real steps to do. --pino 12:54, 28 May 2007 (CEST)
Yes, this article could go back to being more verbose. I suppose what is missing is an explanation of why the shortcuts are used. They are there for a reason. I also don't get the differentiation between real and not real steps; unless we now consider using the shell for what it was designed for as not real. --Aseigo 02:48, 29 May 2007 (CEST)
What's wrong in explicitely telling:
svn co .../kdelibs
mkdir build-kdelibs
cd build-kdelibs
cmake <options> ../kdelibs
make install
After all, we did that with the ./configure && make && make install sequence in KDE 3 times, and that worked quite fine. I still fail why we have to make our things more complicated. Moreover, these macros force fixed paths -- pino 23:43, 29 May 2007 (CEST)

Q: What is cs and cb?

A: This is not a typo. Read the article about setting up your .bashrc. Both cs and cb are bash functions, used to change to the KDE source directory and KDE build directory respectively.

Q: Are there build instructions for other OS?

A: Actually yes, for Mac OS X. There also is kdelibs.com (see also here) which will be merged into this wiki in the future.

Q: Isn't the install prefix, make and make install missing for modules like kdelibs and kdebase?

A: No. The shell function cmakekde handels this, have a look at the file .bashrc.

Q: How can I generate API Documentation for other modules?

A: Try the following code, replacing <modulename> with your desired module:

mkdir -p apidox
cs apidox
../kdelibs/doc/api/doxygen.sh ../<modulename>/

I tried that and got the following: kdedev@PC1:~/src/KDE/apidox$ ../kdelibs/doc/api/doxygen.sh ../kdepimlibs/

      • doxygen.sh
  • $DOXDATA does not name a directory ( or is unset ), tried "/media/kdedev/home/src/KDE/kdepimlibs/doc/common"

What is wrong here? -TMG 23:55, 28 March 2007 (CEST)

Q: I changed the first command of the "Set up QT - Recipe" from cd to cs because I think this was a typo. Am I right??

A: Right --Dhaumann

no, it was perfectly intentional. see the /Getting_Started/Increased_Productivity_in_KDE4_with_Scripts/.bashrc bashrc in the productivity with KDE4 scripts tutorial. it has QTDIR set to ~/qt-copy. this makes sense, actually, since building Qt is done rather differently from the rest of KDE and one may not get Qt from KDE's svn in any case. so yes, it is supposed to be cd, not cs.
*blush* ;) i should read more carefully. --Dhaumann

Notes: ~/install

When installing KDE4, I strongly recommend installing all tools (like dbus and cmake) and kde packages into the same place, e.g. ~/install. Qt is the only exception.

The reason for this is because if you install some packages to ~/kde and some to /usr/local and maybe one in /usr then cmake will generate errors like:

-- It is impossible to order the include directories.

This is not a fatal error, so you will still be able to compile, but you will possibly be using the wrong versions of libraries and this will product problems that are very hard to diagnose.

You may not experience any problems when installed like I advise not to, however I have and you might too in some typical situations.

Please see:


Install CMake modules local

The CMake modules should be installed local into ~/install/cmake/modules or similar. When following the current instructions 6.1: Install additional CMake modules, it's impossible to do a non-root installation, because "kdelibs/cmake/modules/cmake_install.cmake" wants to install the modules to "/cmake/modules". (I didn't install CMake local, because my system already provided CMake > 2.4.3).

I've already tried to do this, fiddling around with CMAKE_MODULE_PATH and DATA_INSTALL_DIR but couldn't get it working.

Does anybody know how to do this properly?

--Eliasp 15:44, 4 January 2007 (CET)

Fixes needed

  • qt-copy: Should we pass the -debug flag? Doesn't Qt install debug information separately by default anyways? Or is that just in the snapshot? --Mpyne
according to ./configure --help, the default is -release in snapshot. --Aseigo 04:33, 14 March 2007 (CET)
  • In the part of the tutorial that describes how to create a new users, shoudn't to have an edit /etc/sudoers to add permitions for kde-devel call sudo? --SilveiraNeto 03:01, 14 March 2007 (CET)
no. why would you want them to have sudo access?


Since the patents expired, why not use giflib?

Old gcc and -pch flag

In Qt part I had problems with error like this: QtForum thread. I had GCC 3.3.X installed. Using -pch flag (as in recipe) get me errors. Someone friendly gave me tip on #kde-devel not to use this flag, although I didn't test it. Instead I've just updated gcc and g++ from debian repositories. Newer version works fine as "Precompiled headers are supported in GCC (3.4 and newer)" Wikipedia pch.

Build status

You might want to include the dashboard link to show which modules currently build and which don't. -- 13:28, 20 March 2007 (CET)

Extra optional software

- openldap - cyrus

If there was a line at the top like:

sudo apt-get install libaaa-dev libbbb-dev ...-dev ...

This would be very useful and save hours. Is this something we should do?

su - kde4 didn't set the variables

after running 'su - kde4' and 'export' i saw that no variables in .bashrc were set, instead the old one (of the system) where set. I tried 'su kde4' and it worked fine. Why is that?

I'm running gentoo 2006.1 amd64

Qt Flags

Are "-pch" and "-qdbus" really needed? The configure script shows that they're enabled by default. --McEnroe 16:49, 19 April 2007 (CEST)

Amount of space needed?

It would be nice to know how much space (roughly, in GB) you need for a setup to build and run the basic things and packages. --Liquidat 03:08, 7 June 2007 (CEST)

KDE® and the K Desktop Environment® logo are registered trademarks of KDE e.V.Legal