Solaris (and OpenSolaris) are Free Software operating systems released under the CDDL by Sun Microsystems. They are vaguely BSD-like. KDE4 runs on this operating system.
The KDE Project on the OpenSolaris site is intended to be the definitive source of information, but this page on TechBase is intended to collect information, porting and compilation guides, etc. Since TechBase is a wiki, this is much easier than going through the OpenSolaris editing process.
Compilation and Installation
Getting KDE4 on your Solaris machine is a three step process: you need KBE, the KDE Build Environment, as it contains a bunch of tools you need to build KDE4 with. Then there are the dependencies, for which we have RPM-style spec files. And then there is KDE4 itself.
KBE Compilation and Installation
KBE is the "KDE Build Environment" which gives you the tools needed to build the dependencies of KDE and then KDE itself. You can get a tarball of KBE and unpack that. SVN is included in there, which we need later. There is also make and cmake and other bits and pieces; vim is also included to soothe the nerves of vi-using KDE people like me.
/usr/sfw/bin/gtar xvzf KBE.tar.gz
These four commands will fetch and unpack and then start the KBE install script. This script will install dependencies that KBE has which are on the Solaris install media (SUNWi2c and twenty others, I think). Then it will start building the packages for KBE itself, starting with pkgtool. It should go off without a hitch (otherwise post output to the mailing list). If it craps out somehow, you will have to start over from scratch: pkgrm -Y KBE ; bash kbe-install.
Once KBE is done installing, you can check with pkginfo -c KBE to see what it has installed. You will have a /opt/kdebld filled with "stuff". Right. Now source the environment from KBE, which you will use in later steps:
(Use env.csh if that's your poison). If you don't have an env.sh at the end, something is definitely wrong. I end up with 210 or so files in /opt/kdebld/bin, so keep that in mind as a metric. There are 23 packages in the KBE group.
Avoiding KBE dependencies
You can give kbe-install a --nodeps to avoid the SUNW packages that it wants to install. You do need to have Sun Studio 12 9/07 or later installed; any later patches are welcome as well. I do not know what avoiding the SUNW dependencies will do, actually: they don't really seem to be essential, but I would suggest skipping this step only if you don't have the install media handy.
If kbe-install does not work, please pop into #kde-solaris on Freenode (irc.kde.org works) and ask questions.
KDE4 has a lot of dependencies. Without getting near to porting all of the optional dependencies for the first four KDE SVN modules, the KDE Solaris team has already done about 50 different Open Source packages. These need to be installed first before you can compile KDE4. The packages range from single header files to Qt 4.3.1, which is kind of big. All of the dependencies are distributed as SysV packages.
Getting spec files
The next part of the equation is getting all of the dependencies of KDE to build. These are numerous, multifarious, and huge. And at least one of them will break. So start off with fetching the tarball with the SPECS, from bionicmutton.org:
/usr/sfw/bin/gtar xvzf SPECS.tar.gz
In the SPECS/ directory you will find a whole bunch of files named FOSS<something>. These are all the dependencies currently packaged. Some of these may conflict with files and packages already sitting in your ~/packages/ directory, so it is safest to remove ~/packages/BUILD/* and ~/packages/SPECS/* and ~/packages/SOURCES/* (but not the directories themselves).
Patching your System
Boost, one of the dependencies, builds Python bindings, and the Python headers installed by the system Python package are broken. So you will have to edit them as root to fix this. Fortunately it will take a while before Boost gets there, so start the make process and then an editor. In /usr/include/python2.4/pyport.h there is a gethostname() prototype that must be commented out. Or get a good copy of pyport.h here.
You will have to source the environment from KBE and then run make. That will start building all of the packages, one by one. You will get lots of lines of output like the following:
pkginfo -q "FOSSexiv2" || pkgtool --download build "FOSSexiv2.spec"
INFO: Copying %use'd or %include'd spec files to SPECS directory
INFO: Processing spec files
INFO: Finding sources
INFO: Downloading source http://www.bionicmutton.org/solaris/EXIV2-0.14.tar.gz
If a package build fails, there will be a /tmp/FOSS*.log file explaining what went wrong. If configure fails in these packages, look for /tmp/config.log as well. Unfortunately pkgtool seems to destroy the build results directory even when it fails; you may also be able to look into ~/packages/BUILD/ to find the directory where things were building.
As usual, the IRC channel is a good place to start, but you must be able to pastebin compilation errors in order to get any help.
KDE4 still builds out of KDE SVN. We have a setup that applies a handful of Solaris-specific patches to the code and then builds everything. We don't use kdesvn-build yet, but probably should when there are no external patches left.
Setting up an SVN checkout
Get a checkout of KDE SVN trunk, like so:
/opt/kdebld/bin/svn co svn://anonsvn.kde.org/home/kde/trunk/KDE
That's a huge checkout. Remember where you put it.
Using the build system
The build system lives in CVSDude SVN, so you need to check it out as well:
/opt/kdebld/bin/svn co https://svn2.cvsdude.com/kdesolaris/trunk/Build
Now is probably the right time to source /opt/kdebld/bin/env.sh again. Notice that Build/ just contains Makefiles. Everything here is driven by (GNU) make.
Configuration is stored in Makefile.config and you can override most of that in a file Makefile.config.local. The contents of my local configuration file are as follows:
DESTRUCTIVE_UNPACK=YESThat ought to be self-explanitory: I have the KDE SVN checkout under ~/KDE.
A good trial run is of the kdesupport SVN module, so run make -f Makefile.kdesupport
The IRC channel is never too busy.