On Mon, Nov 12, 2012 at 05:02:01PM -0600, Amit Kulkarni wrote: > On Mon, Nov 12, 2012 at 3:09 PM, Vadim Zhukov <persg...@gmail.com> wrote: > > 2012/11/12 Amit Kulkarni <amitk...@gmail.com>: > >> all pkgs in kde4 pass compilation with fixes pushed into > >> openbsd-wip... Compiled with cmake 2.8.10. Some small issues while I > >> build kde3 and then the rest of the ports!!!. > > > > Just to be clear: do you want to make KDE 3 and 4 co-build or > > co-exist? Both goals are hard to achieve... > > co-build with dpb -J removing dependencies along the way.
This won't work. This requires lots of hand-holding. dpb will just error out. You will end up with two dpb runs. Here is a bird's eye overview of the choices. Currently we have a rather full set of kde3 which works reasonably well. For kde4 to "replace" that, we need to have *most* applications that were in kde3 working. Yes, this includes most of koffice, digikam, amarok, gwenview... just for applications I'm aware of. I'm not sure kde4 can replace that on every architecture. kde4 was created later, and it's going to use functionalities that might be hard to achieve on older platforms. For instance, all of kde games have switched from bitmaps to SVG. I'm not sure that's reasonable for old platforms. trinity might be a good intermediate point. It's still a lot of work, as the build system is radically different from kde3, so it requires creating new ports (but you can probably lift most of the useful code from kde3). (for those that don't know, trinity is supposed to be kde3 ported to qt4, thus requiring one single qt for both kde3 and kde4). *ideally*, kde3 and kde4 *should* both be able to build on the same box. Using dpb twice is cumbersome at best, and not very realistic for any long term use. That was actually one blocking issue back when I played a bit with kde4. Being able to run both kde3 and kde4 would be best, but at least building stuff on the same box without having to wipe things out would be good. (this requires libraries in distinct directories with symlinks, and some other stuff duplicated, like a separate include dir, possibly a separate pkgconfig dir, and some renamed stuff... I did something awfully similar with qt4 wrt qtconfig/moc... it's not impossible, but it's work). What can be done currently without problems: - update the ports sthen pointed out, either because they're not even used currently, or check carefully that updating them won't give us any hardship. - import more kde4 stuff that's independent from existing stuff. - link all that to the build. Make sure it doesn't break any of the existing stuff. - try to arrange kde4/kde3/trinity to give it a chance to build concurrently. Preferably before import, as it's much easier to do these changes before import. - import kde4 so that people can play with it. If it's easy to build, then people can play with it manually. Even if dpb can't build it all... (maybe at that point we'll have trinity too). Then we will have enough data points to know where to go... it might be that it's actually okay to switch to kde4, and that it's good enough on most architectures. I'm not too sure of that. Note that those steps require careful validations. I've left out some important stuff, like fixing qt4 somewhat, dealing with cmake files, dealing with the phonon mess...
