[kde-freebsd] KDE4/Qt4 porting efforts?
danny at ricin.com
Sun Jan 6 01:43:19 CET 2008
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.
> kde-freebsd mailing list
> kde-freebsd at kde.org
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).
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
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
More information about the kde-freebsd