Op 3 mei 2012, om 13:24 heeft Richard Purdie het volgende geschreven: > On Thu, 2012-05-03 at 12:39 +0200, Koen Kooi wrote: >> Op 3 mei 2012, om 10:47 heeft Richard Purdie het volgende geschreven: >> >>> On Thu, 2012-05-03 at 09:43 +0200, Koen Kooi wrote: >>>> Op 3 mei 2012, om 09:32 heeft Khem Raj het volgende geschreven: >>>> >>>>> On Wed, May 2, 2012 at 7:23 AM, Jason Wessel <[email protected]> >>>>> wrote: >>>>>> The user mode NFS server does not get built by default when you are >>>>>> using a purely command line driven development environment without SDK >>>>>> tools. In order to accommodate simple test configurations and have >>>>>> all the tools built for the minimal validation with qemu-native, >>>>>> simply add the dependency to unfs-server-native. >>>>>> >>>>>> Signed-off-by: Jason Wessel <[email protected]> >>>>>> --- >>>>>> meta/conf/machine/include/qemu.inc | 2 +- >>>>>> 1 files changed, 1 insertions(+), 1 deletions(-) >>>>>> >>>>>> diff --git a/meta/conf/machine/include/qemu.inc >>>>>> b/meta/conf/machine/include/qemu.inc >>>>>> index 421a149..742b629 100644 >>>>>> --- a/meta/conf/machine/include/qemu.inc >>>>>> +++ b/meta/conf/machine/include/qemu.inc >>>>>> @@ -14,4 +14,4 @@ RDEPENDS_kernel-base = "" >>>>>> # Use a common kernel recipe for all QEMU machines >>>>>> PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto" >>>>>> >>>>>> -EXTRA_IMAGEDEPENDS += "qemu-native qemu-helper-native" >>>>>> +EXTRA_IMAGEDEPENDS += "qemu-native qemu-helper-native >>>>>> unfs-server-native" >>>>>> -- >>>>> >>>>> how about replacing EXTRA_IMAGEDEPENDS with >>>>> MACHINE_ESSENTIAL_EXTRA_RDEPENDS here ? >>>> >>>> RDEPENDS end up in the image, IMAGEDEPENDS are needed to build the >>>> image. Do I need qemu-native, helper-native and unfs to build the >>>> image? No I don't. Would I need it if I decide to run the runqemu >>>> scripts, yes. Do these extra dependencies cause pain? Yes, since it >>>> requires installing tons of extra things on a headless buildserver >>>> (mesa, sdl) to just build an image. >>>> >>>> If I wanted to be an ass I would suggest moving qemu-native, >>>> qemu-helper-native and unfs-server-native to the HOB, but I won't do >>>> that. >>>> >>>> So I'll stick with my original suggestion: move those dependencies to >>>> the images you want to run on nfs for qemu, don't pollute the global >>>> EXTRA_IMAGEDEPENDS with it. >>> >>> If I wanted to be an ass here I'd just add them to the image class >>> conditional on qemu. This would be a little pointless and needlessly >>> complicate things though. >>> >>> The point of these is to trigger them to build whenever a qemu image is >>> built. This makes a lot of sense in some use cases, it also does not >>> make sense in some other cases and it is not possible for the system to >>> mind read and tell the difference. >> >> What about having the runqemu* scripts call bitbake to build the >> -native helpers when they are missing? > > The whole point with the qemu emulated machines is that you build them > and they work for new users easily and efficiently. I don't think > calling bitbake to build them and force the user into another wait is a > good usability model to be promoting.
OE-core should set the right example and teaching people that a global IMAGE_DEPENDS is OK is not the right example. Especially when it actually causes breakage, see below. If people insist that IMAGE_DEPENDS is the one and only way to provide the runqemu experience then at least put a big comment in the file saying why it's done and why people shouldn't be copy/pasting it into their layers. And an indiciation where the line is drawn would be nice as well, I can imagine that someone wants to add amazon EC2 support to runqemu and sends a patch to add the EC2 tools to IMAGE_DEPENDS. > I'm also slightly bemused that in previous discussions you've implied > build time is less relevant then functionality yet here you're taking > the opposite stance :). I get build *failures* for the qemu machines because I don't have mesa and sdl installed on the autobuilder. But you are right, I do think build time is less relevant than functionality. _______________________________________________ Openembedded-core mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
