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