All of lore.kernel.org
 help / color / mirror / Atom feed
From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: William Mills <wmills@ti.com>
Cc: Yocto Project <yocto@yoctoproject.org>
Subject: Re: creating global variables in a recipes
Date: Thu, 02 Feb 2012 22:27:00 +0000	[thread overview]
Message-ID: <1328221620.3895.82.camel@ted> (raw)
In-Reply-To: <4F296D48.4080807@ti.com>

On Wed, 2012-02-01 at 11:50 -0500, William Mills wrote:
> I am not sure I can give you a better option that local.conf but I can 
> explain why what your doing does not work.
> 
> It may feel from your usage that the image recipe is the ancestor of all 
> the recipes but this is really not true.  The settings in a image recipe 
> effect the assembly of that image and not the packages that they depend 
> on.  An image could be assembled from packages that were built long ago 
> or inherited via shared state.
> 
> settings in local,conf on the other hand affect all recipes.  If you add 
> something there it will be seen by all recipes.  Unfortunately this 
> means that all recipes are dependent on the settings and everything will 
> need to be rebuilt in case the new setting effects them.  I believe this 
> also means you will not be able to used share state with someone with a 
> different setting of (or unset) SOME_VARIABLE.  (Well you can but you 
> will both be rebuild everything.)

Just a small clarification:

With sstate, it actually depends whether SOME_VARIABLE is used by the
given sstate task or its dependencies. We have variable dependency
tracking code and can tell where variables are used and with what value.

The end result is you can have different local.conf files and share
sstate output in many cases, but real differences to the individual task
inputs will get accounted for.

Cheers

Richard




  parent reply	other threads:[~2012-02-02 22:27 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-31  7:10 forcing a task to run while building an image Joshua Immanuel
2012-02-01  6:37 ` Joshua Immanuel
2012-02-01 15:49   ` creating global variables in a recipes Joshua Immanuel
2012-02-01 16:14     ` Christopher Larson
2012-02-01 16:50     ` William Mills
2012-02-02  5:17       ` Joshua Immanuel
2012-02-02 15:17         ` Chris Larson
2012-02-03  7:13           ` Joshua Immanuel
2012-02-02 22:27       ` Richard Purdie [this message]
2012-02-03 16:13         ` William Mills
2012-02-01 11:04 ` forcing a task to run while building an image Sathishkumar Duraisamy
2012-02-01 11:42   ` Joshua Immanuel
2012-02-01 12:22     ` Sathishkumar Duraisamy
2012-02-01 12:31       ` Joshua Immanuel
2012-02-03  8:04     ` Joshua Immanuel
2012-02-03  8:51       ` Sathishkumar Duraisamy
2012-02-03  9:57         ` Joshua Immanuel

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=1328221620.3895.82.camel@ted \
    --to=richard.purdie@linuxfoundation.org \
    --cc=wmills@ti.com \
    --cc=yocto@yoctoproject.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.