[kde-solaris] KDE 4.0 on opensolaris, howto build

[Adriaan de Groot]

Hi Murad,

On Thursday 30 August 2007, Murad Tagirov wrote:
> sorry, perhaps this is a stupid question but is anybody testing KDE 4
> on opensolaris ? 

As you can see from the traffic on this list, yes, lots of people are trying 
it and testing builds. SInce it doesn't build (easily) yet, we're mostly 
focusing on compilation and dependencies.

> Or does someone has any docs how to build it on 
> solaris and create packages ? I'm interesting is creating kde 4
> packages for opensolaris. If anybody did same job could you please
> share your experience, ;-)

I maintain a build system for KDE4 in CVSDude. It's just a bunch of makefiles 
that download, compile and install the dependencies for KDE and KDE itself. 
Well, as far as I've gotten, anyway. You can get it with

	svn co http://svn2.cvsdude.com/kdesolaris/trunk/Build

This gives you a directory full of Makefiles. Things will be installed as 
follows:

/opt/kdesupport -- everything else
/opt/qt-4.3 -- Qt 4.3.1
/opt/kde-4.0 -- kdelibs and onwards

You can find a little graphic showing the status of the whole exercise in 
Build/Tools/dependencies.png, where green is OK, orange still needs work (see 
annotation) and red is broken; black is untried.

This setup assumes that *nothing* is installed; on an OpenSolaris box (as 
opposed to a Solaris one) it will probably download and build stuff you 
already have. That will bloat up /opt/kdesupport a little.

As a quick start, you might do the following:

# Create directories where work will happen: source tarballs,
# packaged tarballs and build artifacts.
mkdir ~/src ~/packages ~/build
# Create directories where results are installed.
# You may want to do this as root and do a chown on them.
mkdir /opt/kdesupport /opt/qt-4.3 /opt/kde-4.0
# Test run
gmake -f Makefile.kdelibs \
	--no-print-directory \
	WITH_OPTIONAL_DEPS=YES \
	WITHOUT_WITNESSES=IGNORE \
	all-recursive

This will crunch through and print lots of things; the interesting bits are 
like this one:

# [kdelibs] Building dependencies qt kdesupport libungif pcre ...
...
# [libstdcxx] No mandatory dependencies
# [libstdcxx] Witness kdesupport/include/algorithm exists

So to get kdelibs, you need qt and kdesupport and ..., it later checks if 
other bits have already been built. If it looks vaguely sensible to you, you 
can drop the WITHOUT_WITNESSES and then things will actually be built (you 
may also want to drop the WITH_OPTIONAL_DEPS, to get a more minimal system):

gmake -f Makefile.kdelibs \
	--no-print-directory \
	WITH_OPTIONAL_DEPS=YES \
	all-recursive

This will crunch on and on and on. Packages end up in ~/packages/ by default. 
These are just tarballs of the results. Builds -- and more importantly, build 
logs -- are in ~/build/ . This system has a regrettable tendency to carry on 
even when some compilation has failed -- I'm not sure how to break out of a 
shell-based for loop while preserving $? .

Another approach is to use the Makefile (not one of the component makefiles 
list Makefile.kdelibs) which will build things in a predefined order not 
based on dependencies.

gmake

For a little more fine-grained control (I can imagine that libstdcxx is 
problematic), build the C-based dependencies first, then libstdcxx:

gmake ctargets libstdcxx

Note that the KDE modules are assumed to be SVN checkouts mounted somewhere in 
your filesystem (there's no point really in trying to compile the tarballs of 
any of the KDE4 alpha or beta releases so far). The variable KDESVN_DIR sets 
where this is. Actually, you could untar a released tarball somewhere and 
point KDESVN_DIR to its parent.

The CPU is assumed to be a V8 SPARC or an IA32. This affects the build flags. 
I have a V9 SPARC but no 64-bit X libraries, so there is a special setting 
V9-32 to accomodate that. Set CPU= on the gmake command line.

I'm interested in people actually using this setup to build KDE4, since I push 
Stefan's knowledge of build flags and his patches to various bits and pieces 
into here, but I don't know if it works for anyone else. The setup will break 
if you use too many fancy tricks in your machine setup -- I think using GNU 
sed instead of Sun sed already bungs up the trickery used to get libstdcxx 
working.


-- 
These are your friends - Adem
    GPG: FEA2 A3FE Adriaan de Groot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kde-solaris/attachments/20070913/b5b53a8b/attachment.pgp