Openembedded Core Discussions
 help / color / mirror / Atom feed
From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Paul Barker <paul@paulbarker.me.uk>
Cc: openembedded-core <openembedded-core@lists.openembedded.org>
Subject: Re: Ensuring a task is re-ran when local.conf is updated
Date: Fri, 02 May 2014 22:34:05 +0100	[thread overview]
Message-ID: <1399066445.12731.86.camel@ted> (raw)
In-Reply-To: <CANyK_8f74ZEqzX1ve=93GnZ7fg1NEiZUVeOKmmHuY+kHX-UseA@mail.gmail.com>

On Fri, 2014-05-02 at 17:43 +0100, Paul Barker wrote:
> Hi all, I'm wondering if someone can help me debug this problem a
> little as it's getting into the parts of bitbake I don't know very
> well, in particular the determination of whether a task needs to
> re-run or not.
> 
> I've attached a patch which adds code to do_package_write_ipk in
> package_ipk.bbclass to split up the package feed if
> IPK_HIERARCHICAL_FEED is set to "1". The commit message in the patch
> explains why I'm doing this and if it all works I'll submit this to
> master. The attached patch isn't ready for submission yet, it needs
> more testing first.
> 
> As expected, if IPK_HIERARCHICAL_FEED is not set in local.conf, the
> package feed is created in the old way. If IPK_HIERARCHICAL_FEED is
> set to "1" in local.conf, the package feed is created in my modified
> way. This was tested by building from scratch in each case, with no
> sstate or tmp directory present.
> 
> However if IPK_HIERARCHICAL_FEED is changed in local.conf, the package
> feed is not recreated. I can force do_write_package_ipk and the new
> value is taken into account, but if I just do my usual 'bitbake
> kitchen-sink' where kitchen-sink is a packagegroup which depends on
> everything I want in the package feed, do_write_package_ipk is not
> re-ran for any recipe.
> 
> Am I missing something here? Is it expected that this variable change
> is detected and the relevant tasks re-executed? I know changing
> variables like PREFERRED_PROVIDER_* in local.conf causes things to be
> rebuilt, so why does that work and this not?

This should work, I'm not sure why it wouldn't. The code should be able
to detect the dependency on the IPK_HIERARCHICAL_FEED variable and
notice when the value changes.

I'd have to experiment with some builds to figure out anything further
but its probably worth opening a bug report as it sounds broken.

bitbake-dffsigs on a siginfo file of a do_package_write_ipk is where to
start with debugging, it should show the dependency on the variable.

Cheers,

Richard



  reply	other threads:[~2014-05-02 21:34 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-02 16:43 Ensuring a task is re-ran when local.conf is updated Paul Barker
2014-05-02 21:34 ` Richard Purdie [this message]
2014-05-02 21:51   ` Paul Barker
2014-05-02 22:07     ` Richard Purdie
2014-05-03  9:03       ` Burton, Ross
2014-05-03  9:08         ` Richard Purdie
2014-05-03 20:46           ` Burton, Ross

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=1399066445.12731.86.camel@ted \
    --to=richard.purdie@linuxfoundation.org \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=paul@paulbarker.me.uk \
    /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