[kde-freebsd] KDE4/Qt4 porting efforts?

[Danny Pansters]

On Saturday 05 January 2008 09:42:41 Shane Bell wrote:
> On Sat, 05 Jan 2008 09:42 am Adriaan de Groot wrote:
> > On Friday 04 January 2008 20:54, Mikhail Teterin wrote:
> > > How is the subject coming along? It seems, some new things like
> > > "strigi" are required for kdelibs-4 -- but I don't see a port of that
> > > in the tree yet... Would you like it added?
> >
> > All the things in kdesupport should have ports created. Since they depend
> > only on Qt4 (and possibly other things) this should be fairly
> > straightforward. Bear in mind that their build systems are CMake-based.
> > I'm not sure there's any infrastructure for CMake-based ports yet.
>
> I've got a port for strigi here that's about 90% complete, but I've been
> waiting for a couple things, namely:
>
> - The next release of strigi, because it will make OPTIONS handling in the
> port a lot more neater/easier.
>
> - Updated Qt4 in ports. bombs on qt from ports(iirc something to do with
> moc), works fine with svn qt-copy though.
>
> I also made a simple bsd.cmake.mk a few months back. Never tested it out
> though, so ill have look it and make it available when I'm done.
>
> shane.
> _______________________________________________
> kde-freebsd mailing list
> kde-freebsd at kde.org
> https://mail.kde.org/mailman/listinfo/kde-freebsd

I never found the time and/or inspiration to persue it further, but I created 
a few "kitchen sink" type ports for kdesupport4, kdelibs4, kdebase4, 
kdepimlibs4 back in September. It compiled and I could start the desktop but 
(as Adriaan has also blogged about and somewhat worked around) knotify4 
barfed really bad.

<sidenote type='related though'>
IMHO both xine and gstreamer were piss-poor choices for the a/v backend, they 
should have built their own infrastructure around ffmpeg instead which in any 
event is the *real* a/v engine that eventually gets used, would have left the 
multimedia backend framework basically up to themselves, possibly manpower 
shortage was the main reason for this?
I think eventually I'm going to try and make kbtv(2) a backend for the capture 
stuff (somewhat like v4l).
</sidenote>

While these preliminary ports won't work as-is now, there's probably a lot of 
useful info, and they contain many REINPLACE_CMD lines that are for peaceful 
qt3/qt4 co-existance (both installed in /usr/local). Most of those will 
probably still be applicable and they really should go upstream (most linux 
distros had qt3/kde3 under /opt, so they don't see any of those qt4 vs qt3 
problems).

So FWIW, they're at http://freebsd.ricin.com/kde4ports_sept2007.tbz

You should extract it in your PORTSDIR. I'm pretty sure it can at least save 
some people some time.

A good bsd.cmake.mk would be very useful I think (CC and CFLAGS might need 
some looking into). Cmake is quite awesome, if used correctly. It has many 
features that are functionally the same as our ports infrastructure. It's not 
another autohell. But I can't say that I fully grasp all of its features and 
possibilities, and what's mostly needed I think is for someone to define some 
set of best/recommended practices. A bsd.cmake.mk is the perfect place for 
that. I admit to have daydreamed a little over a "cports" concept. It really 
is that useful and flexible.


Cheers, and happy new year

Dan