On Tue, Jun 21, 2011 at 11:54, Koen Kooi <[email protected]> wrote: > > Op 21 jun 2011, om 11:34 heeft Anders Darander het volgende geschreven: > >> On Tue, Jun 21, 2011 at 11:12, Phil Blundell <[email protected]> wrote: >>> On Tue, 2011-06-21 at 16:08 +0800, Dongxiao Xu wrote: >>>> -DEPENDS = "libgdbus dbus glib-2.0 hal iptables" >>>> -RDEPENDS_${PN} = "wpa-supplicant resolvconf" >>>> +DEPENDS = "libgdbus dbus glib-2.0 hal iptables ofono wpa-supplicant >>>> resolvconf bluez4" >>> >>> What does the dependency stack for ofono look like? If it's non-trivial >>> then I am not sure it is a good idea to add ofono to DEPENDS >>> unconditionally. >> >> Although Koen showed that the dependcies were quite trivial, I'd >> prefer to not build ofono if it is possible. >> >>> Ditto bluez4, I don't think that should be in there unless >>> DISTRO_FEATURES requested it. >> >> Yes, I certainly agree with you on bluez4. If we don't have bluetooth >> enabled for our machine/distro, I definitely prefere to not build it. >> >> To me it's not only about the risk that we increase the rootfs, but >> also about build-times. Even if we have quite fast machines today, it >> is a waste of CPU cycles to build lots of SW that aren't going to be >> used... >> >> Adding a dependency etc is easily done in a bbappen-file, which makes >> the reversed desire quite easy. I'm not sure if there is an easy way >> of removing item from e.g. DEPENDS and EXTRA_OECONF etc. > > I'd trade extra build time over not having to use bbappends anytime. > Especially where upstream has proper plugin support like connman.
In cases like connman (with proper plugin-support, and a good packaging), yes, then it is only about build time. And sure, in some cases I completely agree with you. However, occasionally when building a really tiny image adding a small package could result in a complete build of X and lots of other stuff. In such cases it's not always that funny. (Sorry, it was a long time ago on .dev that this happened, so I don't remember what package it was). Apart from these kind of situations, it's normally not a big problem, unless you're in a development stage where you need frequent clean rebuilds... (Another drawback, although it is really only on the first build, is that building lots of unnecessary packages increases the risk of build/fetch problems.) Currently I can't access cgit.openembedded.org (probably the local network), so I can't check it. But isn't e.g. bluetooth found somewhere in either DISTRO_FEATURES or MACHINE_FEATURES? If so, bluez4 and configure options should probably be set conditionally. /Anders _______________________________________________ Openembedded-core mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
