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
prev parent 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