[kde-freebsd] KDE4 is out, I'm back, let's get cracking

[David Naylor]

On Monday 14 January 2008 18:30:27 Michael Nottebrock wrote:
> Hi guys,
> Step 1 is deciding what to do about that nice boulder that Novell^WKDE
> rolled in our path: prefixes. You cannot build KDE4 in same prefix as
> KDE3. Period. You cannot easily build KDE4 either if KDE3 is in
> /usr/local and if Qt3 is in /usr/local and KDE4 is supposed to end up
> somewhere in /usr/local. I'd like to hear about experiences from people
> who already built large parts of KDE4 on systems with KDE3 installed -
> how much effort and hackery do we need to make things build with leaving
> Qt3 where it is? Would it be worthwhile to just make a clean cut and
> move Qt3, Qt4 and KDE3 into their own subdir below /usr/local after all?
> I am prepared to do it, if need be (I suppose nobody wants to go down
> the CONFLICTS road).

I have compiled kdelibs and kdebase-* with both qt3 and kde3
installed.  There was plenty of problems with kde4 picking up kde3
stuff but once FindQt4.cmake and FindKDE4Internal.cmake had been
changed to make sure -I/usr/local/include was at the end of the list
then no problem (of course kde4 installed into its own prefix, under
/home/kde4/usr :-).  All you need to do is juggle around the
QT_INCLUDES and KDE4_INCLUDES set directives (there are two
QT_INCLUDES set directives)

I ran kde4 and so far a few apps crash, since my laptop has limited
memory I haven't done many backtraces but the one I did showed
kcm_init (or something) was in fact picking up qt3 libs.  It seemed
much slower than KDE3 (on memory limited computer) but I'm not sure...

(((
Quick question, which files should be changed to make sure PATH and
LD_LIBRARY_PATH is set properly for running the session (and which .X*
file to make kdm (v3) run KDE4 automatically.) Thanks
)))

Given that KDE4 is not yet a drop in replacement for KDE3 I recommend
we place KDE4 in its own prefix and when it is ready swap them, and
then wait for the day when KDE3 is removed from ports (in many years
to come...)  I like the idea about KDE4PREFIX, perhaps we could start
on KDE3PREFIX to allow easy change in distant future.

> Step 2 will be getting all the modules to build and to run somewhat
> reasonably. It will be just like the old days, lots of swearing and
> patching and 80% of KDE working in the beginning and 95% of KDE working
> just before KDE5 will come out. :)

I could start tracking down programs that don't run (so far everything
compiles).  What should I do with the backtraces and list of programs
that crash?

> Step 3 will be cutting up the distribution modules into smaller pieces
> whereever possible/sensible and possibly write a kde.mk for the task.

Sounds like a good plan (could perhaps use --exclude when unpacking sources?)

(((
Another quick question, since kdelibs insists on an out-of-source
build (easily overridden) and cmake supports in very well will such a
capability be put into bsd.cmake.mk (and used by default?).  Oh, how
is bsd.cmake.mk coming along?
Thanks again
)))

David