I've had success in modeling kopete-[plugins|protocols]-* after akode-plugins-*, but now I've got a few more questions.
First: building libkopete. See, the akode port builds by removing the "plugins" subdirectory from its Makefile via a patch; similarly, each plugin removes all subdirectories besides itself (obviously) and lib, since the plugins need the headers and libraries in the parent directories in order to build. For libakode, this is fine, but libkopete is rather large -- on my machine, it takes a few minutes to build, while most plugins take only a matter of seconds. If a user were to build all 10 protocols and 16 plugins, this would involve rebuilding libkopete 27 times, although it would only be installed once. For the binary packages, of course, this won't be a problem, since they'll just get the installed files, which are not at all duplicated. So much for the goal of saving build time. Is there a more efficient way to do this? Second: there are some hidden protocols and plugins -- that is, they are present as directories in the source tarball, but they don't build by default, at least not in the current kopete port. The Meanwhile protocol seems to need a separate library download (there is a README file in its directory), and I can't figure out what the smpppd plugin is supposed to do. I also can't figure out why the SMS protocol is not set to build with the monolithic kopete. What should be done with these mystery plugins? Third: which plugins/ports should be enabled by default in the OPTIONS? - Daniel W. Steinbrook On Tuesday 12 June 2007 12:51:03 pm you wrote: > Daniel W. Steinbrook schrieb: > > I'd be willing to tinker with this. I like taking on little, fun FreeBSD > > projects for which others don't have time. > > Great! > > > A couple of initial questions: > > - There are 10 protocols and 16 plugins. This would be 26 OPTIONS for > > kopete. Would it be better to create two meta-ports, kopete-protocols and > > kopete-plugins, which each have their own options? > > Perhaps, but it seems a lot of work only to avoid some scrolling in > dialog(1). Your call! :) > > > - Should the PKGNAMEPREFIX be kdenetwork- for each of the individual > > protocols/plugins, as it is currently for net-im/kopete? This would make > > for some long package names (e.g. kdenetwork-kopete-protocols-groupwise). > > That's not a problem IMHO. > > Cheers, _______________________________________________ kde-freebsd mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-freebsd
