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 _______________________________________________ kde-freebsd mailing list kde-freebsd@kde.org https://mail.kde.org/mailman/listinfo/kde-freebsd
