But I Downloaded Source Code!
Good for you! With no offense intended toward those who take the binary route—compiling KDE2 does take some time—if you can build it yourself, you can optimize it for your machine, you will be more likely to repair any problems that might arise, and you will have exhibited a familiarity with Linux that will make some of the things in KDE2 that aren't working yet a little easier to swallow.
What you do with the source depends largely on the drive space that is available; a lot of space can uncomplicate things, especially if you use CVSUP and plan to use it again and again as KDE2 moves closer to release. Whatever the case, exit KDE (if it's running) so that you're at a pure console session. The first issue is our old friend QT.
The qt-copy package should be copied someplace[md]/usr is fine. Then use tar xvfz to unpack it. If you currently have a /usr/lib/qt that is a symbolic link to, say, /usr/qt144, delete it. However, if qt-1.44 itself actually resides at /usr/qt, you'll need to move it to, say, /usr/qt144, in the same way your KDE-1.1.2 got moved from /opt/kde to /opt/kde112 earlier in the article. Now, make a symbolic link from qt-copy to /usr/lib/qt:
ln -s /usr/qt-copy /usr/lib/qt
If you're already running a version of KDE, you won't need to change the environment variable for QT because you're putting the new version, via the symbolic link, in the same place where the old one resided. But if this is your first KDE experience, you'll need to set the environment variable as specified in the /usr/qt-copy/INSTALL; you will need to alter the specified paths to point the $QTDIR to /usr/lib. Now you're prepared to build the new QT. If you're not there already, change to the QT directory. Then do this:
make -f Makefile.cvs ./configure -sm -gif -system-libpng -system-jpeg make
You will need to await the return of the command prompt between each of these. The -gif option for the configure command is used because of copyright issues: QT may not enable .gif file support by default, but you may do it manually.
The make process takes quite a while. It might be done in minutes on the best-of-all-possible machines, but for the rest of us it may take up to an hour. When it's done, you're almost ready to build KDE2; however, you do have a decision or two to make first.
With unlimited drive space, you can copy all of the KDE2 source tarballs to /usr/local/src/kde; you can do likewise if you have used CVSUP to copy all of your /home/kde (or whatever directory name you chose) to /usr/local/src/.
KDE2 (in fact, all KDE) source tarballs are compressed using bzip2, which is more efficient than other popular compression methods. So, for the tarball folks, it's a good idea now to change to /usr/local/src and do the following:
bzip2 -d kde*
This uses the bzip2 program to decompress all files in the directory that begins with the letters "kde." This doesn't take long, but it does take long enough (a few minutes) to make you wonder if something has gone wrong. If you don't get error messages echoed to the screen, everything is okay. To unarchive each package in turn, you use this line:
tar xvf [packagename]
There are a lot of packages; it's useful to untar them one at a time as you compile them. Then, if you get distracted, you'll be able to easily tell which ones you've built and which ones you haven't. In any case, kde-common is the first one to do because all the others rely on it.
CVSUP users don't have to worry about unpacking the files, whose compression was brief and during the download only. They're ready to go. What you do have to worry about is whether you have an additional 100-plus MB of space in /usr/local/src for a copy of the whole source tree. If not, it can be built in situ in the directory into which it was downloaded. (This involves a little complication, which we'll discuss shortly.)
Wherever the source is located, the first package to deal with is kdesupport. Change to that directory; snapshot users should untar it and then change to it. Then do this: ln -s ../kde-common/admin ./
This creates a symbolic link between the /admin subdirectory of /kde-common and the current directory. You will need to do this for each KDE2 package you build. Then comes this line:
make -f Makefile.cvs
This prepares the files that are necessary for the configure command to do something useful. This will need to be done for each package. As with creating the symbolic link to kde-admin, this is not something that happens in release versions of KDE or in other source packages, so it's easy for even experienced compilers to overlook. Next, unsurprisingly comes this line:
But don't stop with just ./configure—here is where you specify not only where your KDE2 will end up, but also how well it will run when it gets there. You can even specify the size of the code, which affects both the storage space required and the time that is necessary to load the files created. The command accepts not just a number of options, but compiler flags as well. For instance, you probably have a Pentium-class machine (this includes AMD K6-2s). Unless you would like to become actively involved in development, creating lots of debug code won't do anything but slow you down. Additionally, you'd like to specify where your newly compiled programs will ultimately reside. To bring about these things, rather than using plain old ./configure, enter this at the command line:
CXXFLAGS=' -mpentium'./configure --prefix=/opt/KDE2
With this, you've told your C++ compiler that it should compile Pentium-optimized code; you've also determined that configure should plan on the results of compiling into the specified directory, and you've specified that configure need not bother with all that debug code. Yes, the single quote goes immediately after the equals sign and is followed by a space. (If you are experienced and have other favorite compilation flags, you can use them here, too.) The ./configure process will take a minute or two for kdesupport; for some packages, it can take 10 minutes or more. When it's done, enter this line:
Now the code is actually compiled. It will take approximately 10 minutes for kdesupport; for the more elaborate packages, such as kdebase or koffice, it will take a lot longer. But in due course, you are returned to the command prompt, which you treat to:
The binaries you've compiled will now be installed into /opt/KDE2.
Next, you do the same thing—the same thing, no changes[md]to other packages, in this order: kdelibs, kdebase, and then others—the order is up to you. The whole process takes several hours and can be rather tedious, unless you happen to enjoy watching it (and if your heart doesn't flutter when you see a warning message, because at this stage there are many). Fortunately, you don't have to hover over your machine during this process—the KDE developers put a useful bell into the code so that when it's done, your computer's speaker will beep. (This is a good time to clean up the office or go through those boxes and boxes of floppies you've been meaning to do something—what?—with.) But before the seasons change, it will all be done and installed[md]even koffice.
If you have been using KDE, now you need to delete the symbolic link that points to /kde112 and create a new one:
rm /opt/kde ln -s /opt/KDE2 /opt/kde
Now you can exit root, become yourself again, type whatever command you're accustomed to typing to start KDE, and look at KDE2.
Those who haven't used KDE before should back up their /home.xinitrc or /home/.xsession file, as the case may be, and replace it with one that says, simply, startkde. Having done that, the startx command will start KDE2.
If you had the disk space to copy the whole tree over to /usr/local/src/kde, great. Remember to delete it before you build a new CVSUP version of KDE2. But if you built KDE2 using the actual downloaded source and not a copy of it, make sure to enter each package directory before you run CVSUP again, and enter this line:
The binaries you built are now deleted, as are the makefiles and other things. The source is restored to pristine condition.