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

[Danny Pansters]

On Wednesday 16 January 2008 21:33:20 David Naylor wrote:
> On 15/01/2008, Michael Nottebrock <lofi at freebsd.org> wrote:
> > On Monday, 14. January 2008, David Naylor wrote:
> >
> > That sounds like we might get away without moving existing ports to a
> > different prefix after all. Good news! I have added a patch to the Qt4
> > ports which eliminates the /usr/local/include path from the pkg-config
> > files they install, no idea if that will help with KDE4 but perhaps it
> > might.
>
> Did Qt4 ever place header files in include/?  If they did and you've
> moved them out then that helps a lot.  The problem is that the cmake
> scripts include include/ it however it is trivial to remove it.  I'll
> post a patch that will get kdelibs to compile with kde3 and qt3
> installed, if it is not done by Sunday please pester me until it is
> done.
>
> > kdm executes .Xsesssion when the session type is 'Custom'. If you want
>
> Thanks, done
>
> > Also, default prefix moves are always a horrible experience for users -
> > just remember the big X11 move not so long ago. Thus I would very much
> > like to find one location for KDE4 now and then stick with it forever.
>
> I personally prefer not to have ports in their own prefixes when they
> can fit into the default (local/).  This can cause problems with path
> resolution.  Relocation at a later date will not work so well if KDE3
> will survive for a long time and co-exist with KDE4, so I think your
> choice is correct (and KDE4 could be moved back into local if needs
> be, once kde3 is dropped)
>
> One issue is with kde apps with the same name, if they are not
> referred to by full paths, which one gets preference.  Depends, I
> think, which is the default desktop, 3 or 4.  This could be setup
> using rc.d/ scripts with PATH being set to give priority to either
> local/ or kde4prefix/?  (And get kdm running using them as well?)
>
> > Also, default prefix moves are always a horrible experience for users -
> > just remember the big X11 move not so long ago. Thus I would very much
> > like to find one location for KDE4 now and then stick with it forever.
>
> I found it made life easier (but I wasn't involved in the porting effort!)
>
> > You could put them (or links to them) on the wiki:
> > http://wiki.freebsd.org/KDE4. Account creation is open to everyone, but I
> > think arved@ would need to give you write access to the page first (I'd
> > like write access as well btw, account is MichaelNottebrock :).
>
> I'll send in a request this weekend (for you as well).  I've saved two
> back traces for crashed apps.  Strange there is qt_m.so.3 is in them?

Qt3Support?

> I've post another e-mail titles 'Qt4 crashed by Qt3 libs!', it will
> provide some details.
>
> > Does out-of-source build mean builddir!=sourcedir?
>
> Yes, and kdelibs (possibly every other kde package) demands
> out-of-source builds.  It can be disabled but I'm not sure if a build
> would then work?  I just do:
> mkdir $BUILDSRC/build
> (cd $BUILDSRC/build; cmake ../; make)
> to get it to compile (with all variables set for cmake)
>
> > At the moment it is vaporware(?), but I agree we should have one in place
> > at least once kdelibs and kdebase are in good shape.
>
> I could create a bsd.cmake.mk this weekend if it is urgently required
> (it will be my first such file...)?

It's not urgently required, but a starting point would be great. Just start 
with one that sets CC, CXX, etc. and pulls in cmake, and (maybe) have some 
unambigious place to put macros (such as those from kde4) that aren't already 
included with cmake.

Barring the latter, everything should be known (and already used in existing 
ports) and it should be easy to whip something up!

E.g. -- from one of my ports:

CMAKE_ARGS=    -DCMAKE_C_COMPILER:STRING="${CC}"\
                           -DCMAKE_CXX_COMPILER:STRING="${CXX}"\
                           -DCMAKE_C_FLAGS:STRING="${CFLAGS}"\
                           -DCMAKE_CXX_FLAGS:STRING="${CXXFLAGS}"

... etc, and then (optionally) let the default configure target run cmake

cd ${WRKSRC} && ${CMAKE} ${CMAKE_ARGS} .

It's possible to make certain macros dis/en abled but that's all stuff that 
can be played with later. Let's just have something simple and then while 
progressing, certain sub-problems can be moved to cmake.mk

> Thank you for your reply
>
> David
> _______________________________________________
> kde-freebsd mailing list
> kde-freebsd at kde.org
> https://mail.kde.org/mailman/listinfo/kde-freebsd