Openembedded Core Discussions
 help / color / mirror / Atom feed
From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Piotr Lewicki <piotr.lewicki@elfin.de>,
	"Burton, Ross" <ross.burton@intel.com>
Cc: OE-core <openembedded-core@lists.openembedded.org>
Subject: Re: recipe using environment variable does not refresh / rebuild
Date: Thu, 01 Feb 2018 15:09:51 +0000	[thread overview]
Message-ID: <1517497791.3090.50.camel@linuxfoundation.org> (raw)
In-Reply-To: <a7dc8b5e-b277-27c7-b879-4405c1bb04ac@elfin.de>

On Thu, 2018-02-01 at 16:00 +0100, Piotr Lewicki wrote:
> Hi Ross,
> Good idea, but I'm using gitlab to perform autobuilds and I want to
> set the variable there (the "ADD_UBOOT_TO_UPDATE" variable) so that
> it's propagated to the image recipe.
> I'm want to differentiate the image with and without u-boot only by
> setting this one environment variable and without additional mangling
> with local.conf.
> 
> If that's not possible- I'll use your idea with setting it in
> local.conf, but before that I'm trying to understand- why my recipe
> is not rebuilt?

It isn't rebuilt as bitbake isn't psychic!

Bitbake doesn't understand what anonymous python fragments do, so it
can't know that ADD_UBOOT_TO_UPDATE is being changed.

I have a suspicion that it might rebuild, *if* it knew it had to
reparse the recipe since it probably does know which tasks use that
variable. It doesn't know you're poking into BB_ORIGENV which you
really shouldn't be doing.

To make this work as you'd want, you could add ADD_UBOOT_TO_UPDATE to
BB_PRESERVE_ENV. That might be enough to cause it to re-parse each time
you change the value and in turn, if the tasks change based on that,
they might rebuild. I'd at least start there (and stop poking into
BB_ORIGENV).

Cheers,

Richard




      reply	other threads:[~2018-02-01 15:09 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-01 14:46 recipe using environment variable does not refresh / rebuild Piotr Lewicki
2018-02-01 14:50 ` Burton, Ross
2018-02-01 15:00   ` Piotr Lewicki
2018-02-01 15:09     ` Richard Purdie [this message]

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=1517497791.3090.50.camel@linuxfoundation.org \
    --to=richard.purdie@linuxfoundation.org \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=piotr.lewicki@elfin.de \
    --cc=ross.burton@intel.com \
    /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