Openembedded Core Discussions
 help / color / mirror / Atom feed
From: Jason Wessel <jason.wessel@windriver.com>
To: Patches and discussions about the oe-core layer
	<openembedded-core@lists.openembedded.org>
Cc: Koen Kooi <koen@dominion.thruhere.net>
Subject: Re: [PATCH] qemu-native: depend on unfs-server-native
Date: Thu, 3 May 2012 05:57:56 -0500	[thread overview]
Message-ID: <4FA264B4.4080404@windriver.com> (raw)
In-Reply-To: <D8900CA0-6986-4242-8AF1-7A65CC86FDDA@dominion.thruhere.net>

On 05/03/2012 05:39 AM, Koen Kooi wrote:
> 
> Op 3 mei 2012, om 10:47 heeft Richard Purdie het volgende geschreven:
> 
>>
>> 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? 
> 

Clearly this works from the usability angle of keeping a minimal number of steps, but there are two side effects because it is implemented as a "if helper binary exists ; then bitbake ...".  

1) Everything you need to get started was not really there after completing the build
2) If the qemu helpers are updated they will not get rebuilt when you run your typical rebuild
    *** NOTE I realize that this probably does not happen too often, but it is a possibility

I would certainly not want bitbake to run each time you invoke runqemu to check if it is updated because that unnecessarily delays the start of the simulator.  It would seem to me the best approach is to use Richard's idea so as to allow folks to not build the helpers if someone really doesn't want them, as well as have runqemu auto build the helpers if they are not there so as to keep the use cases simple.

Respectfully,
Jason.



  reply	other threads:[~2012-05-03 11:07 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 [this message]
2012-05-03 11:24         ` Richard Purdie
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=4FA264B4.4080404@windriver.com \
    --to=jason.wessel@windriver.com \
    --cc=koen@dominion.thruhere.net \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox