All of lore.kernel.org
 help / color / mirror / Atom feed
From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Patches and discussions about the oe-core layer
	<openembedded-core@lists.openembedded.org>
Subject: Re: [PATCH] qemu-native: depend on unfs-server-native
Date: Thu, 03 May 2012 12:24:01 +0100	[thread overview]
Message-ID: <1336044241.30113.73.camel@ted> (raw)
In-Reply-To: <D8900CA0-6986-4242-8AF1-7A65CC86FDDA@dominion.thruhere.net>

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 <jason.wessel@windriver.com> 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 <jason.wessel@windriver.com>
> >>>> ---
> >>>> 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.

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 :).

Cheers,

Richard






  parent reply	other threads:[~2012-05-03 11:33 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-02 14:23 [PATCH] qemu-native: depend on unfs-server-native Jason Wessel
2012-05-02 14:29 ` Koen Kooi
2012-05-02 14:32   ` Martin Jansa
2012-05-02 14:33   ` Jason Wessel
2012-05-02 14:44     ` Koen Kooi
2012-05-02 21:37       ` Jason Wessel
2012-05-03  7:22         ` Koen Kooi
2012-05-02 21:49       ` Phil Blundell
2012-05-02 22:06         ` Mark Hatle
2012-05-02 22:12         ` Jason Wessel
2012-05-03  7:32 ` Khem Raj
2012-05-03  7:43   ` Koen Kooi
2012-05-03  8:47     ` Richard Purdie
2012-05-03 10:39       ` Koen Kooi
2012-05-03 10:57         ` Jason Wessel
2012-05-03 11:24         ` Richard Purdie [this message]
2012-05-03 11:39           ` Koen Kooi
2012-05-03 11:51             ` Richard Purdie
2012-05-04  6:13               ` Koen Kooi
2012-05-04  6:32                 ` Martin Jansa
2012-05-04  6:50                   ` Koen Kooi
2012-05-04  9:32                     ` Richard Purdie

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1336044241.30113.73.camel@ted \
    --to=richard.purdie@linuxfoundation.org \
    --cc=openembedded-core@lists.openembedded.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.