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

Revision as of 22:12, 11 December 2007

This article is fat

When I first wrote this article, it was lean and mean and simple to understand. And it was good for all distributions. Now I have the impression of a fat pig when I read this article. I pledge for removing the usual sources of error, e.g. the many subdirectories. Why do we need a directory KDE, for example ? If a tutorial is not simple, it is not done.

--Tstaerk 14:23, 9 September 2007 (CEST)

+1. A cleanup would be nice, especially before the official 4.0.0 release! Volunteers needed who do this. --Dhaumann 22:52, 9 September 2007 (CEST)

This tutorial is fine by me. Okay, that's not for newbies, but someone who wants to compile KDE4 RC1 needs to know how to follow this tutorial at least. --Chackal_sjc 06:56, 27 November 2007 (CEST)

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.

the heading says pre-requirments are to read "Anonymous SVN Quickstart Guide" first. but the things it does are mostly done in this guide(but a little differently). for example the "Anonymous SVN Quickstart Guide" has you just svn a bunch of stuff.... but that all ended up in the wrong place cause in this guide the svn'd stuff needed to go to "kde-devl"-user's dir not the normal user dir..

This tutorial clearly states: "The rest of this tutorial assumes you are running as the kde-devel user." -TMG 14:16, 25 June 2007 (CEST)

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)

I am also for removing cb and cs, somebody should just do it. They are indeed confusing and sometimes don't work as expected (that is why cd $KDE_SRC is needed in one place). cmakekde on the other hand could stay IMHO. -TMG 14:16, 25 June 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: 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 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:

http://developer.kde.org/build/trunk.html

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?

libungif/giflib

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. --141.35.8.106 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)

Fixed. Also got rid of openssl for the same reason Logixoul 18:03, 5 July 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)

4.5 GB --Logixoul 18:12, 5 July 2007 (CEST)

Install error?

With the kdesupport package I have an install error: CMake Error: Error in cmake code at /media/local/kde-devel/kde/build/kdesupport/qca/plugins/qca-logger/cmake_install .cmake:35: FILE cannot create directory: /usr/lib/qt4/plugins/crypto. Maybe need administrative privileges. Current CMake stack: /media/local/kde-devel/kde/build/kdesupport/cmake_install.c make;/media/local/kde-devel/kde/build/kdesupport/qca/cmake_install.cmake;/media/ local/kde-devel/kde/build/kdesupport/qca/plugins/cmake_install.cmake;/media/loca l/kde-devel/kde/build/kdesupport/qca/plugins/qca-logger/cmake_install.cmake make: *** [install] Error 255

Why is it trying to install that system wide?

Have you installed local copy of qt4 as described in this tutorial? I had the same error while trying to skip installation of local qt4 copy and use system-wide installed one. The error is gone with local copy of qt4.

I checked back, and the problem is that the script tries to install "libqca-logger.so" to $QTDIR - any idea how to change that?

Did you set $QTDIR to the correct value? Make sure you use the .bashrc so that all environment variables are correct. -TMG 14:25, 25 June 2007 (CEST)

The entire point is that $QTDIR has to be set to /usr/lib/qt4/ - because I use the system wide installed copy of Qt 4.3!

So the problem is not that $QTDIR is set wrong but that the script tries to install something to $QTDIR. --141.35.185.149 23:38, 3 July 2007 (CEST)

Well, then you probably need to install with sudo to get the file installed. I guess it needs to be in the Qt directory because otherwise, Qt doesn't find the files. -TMG 17:31, 4 July 2007 (CEST)

Wrong line numbers (and explanation) in the "What's Happening" section for Qt part.

Line numbers:

Once the patches have been applied, we then set up the build using the configure script (line 5-7). Finally, we build the minimal requirements for KDE (line 8)...

It should be 5-6 for configure and 7 for make.

Explanation is wrong because there is no make install command. And this directory will be used directly. But in the article: "...we build the minimal requirements for KDE (line 8) and install (line 9-10) Qt". But in lines 9-10:

1. if we don't install, we'll just clear obj files to
2. save disk space

Best regards, powerfox.

Wrong directories?

Why does the recipe for kdesupport only say "cs" before getting the source and building while the "cmakekdeall" function in the example .bashrc says "cs KDE/kdesupport && svn up && cmakekde"?

It should either use the KDE subfolder or it shouldn't but now I'm confused as to which of the two is right.

Problem with required soprano version (Kubuntu Gutsy Gibbon)

(sorry for grammar errors if they occur) So,

I,m using Kubuntu Gutsy Gibbon and I had problems with soprano library at installing kdelibs.

cmakekde requires to install kdelibs the version of soprano library, which does not exist in ubuntu repositories. The needed version you can find e.g. here: http://ubuntu2.cica.es/ubuntu/ubuntu/pool/universe/s/soprano/

From this website you have to download libsoprano-dev and libsoprano4 having the same suffix (e.g. ubuntu1~gutsy1_all.deb if you are using Kubuntu Gutsy Gibbon).

Go to directory where you downloaded packages and install each package using dpkg ( I have forgotten the order, so try and when something goes wrong, dpkg shows an information and proposes a solution).

After this remove ~/kde/build/KDE/kdelibs/CMakeCache.txt and try again to install kdelibs.

Good luck :)

• It was damned hard to find, but libsoprano-dev in Gutsy is 1.96.0, and kdelibs requires >=1.97.1. The article says "in this case you need to download and build the relevant part of kdesupport", but as long as the package is installed, cmakekde prefers the files in /usr/include to those under ~/kde/include. Only after removing the package, I was able to move forward.
• I think the real fix should be to make cmakekde prefer the local versions of include files and libraries, but until then, we should at least fix the procedure for Gutsy - please remove libsoprano-dev from the list of packages to install.
• Thanks, Shai. 19:53, 28 November 2007 (CET)
• kdelibs requires Soprano >=1.99 --> Build kdesupport and remove package libsoprano-dev and libsoprano4 : make all folks - chatmoa - 11Dec2007

Possible errors about required packages in openSUSE?

I've been trying to set up a KDE4 development environment today on a openSUSE 10.3 system and encountered the following (possible) errors in this article:

Missing packages:

kdevelop3 - David Faure's cmakekde bash function uses Kdevelop3 as makefile generator. Without the kdevelop3 package cmake fails to start on my install.

strigi-devel - Building kdelibs fails if strigi-devel is not installed

Questionable packages:

Following a gut feeling I'd like to ask why the following packages are required for setting up a KDE4 development environment:

strigi strigi-ui kdesdk3