[OE-core] Task after do_package repeating despite stamp

[Richard Purdie]

On Thu, 2012-03-15 at 19:13 +0000, Daniel Lazzari wrote:
> >Date: Thu, 15 Mar 2012 08:19:54 +0000
> >From: Richard Purdie <richard.purdie at linuxfoundation.org>
> >Subject: Re: [OE-core] Task after do_package repeating despite stamp
> >To: Patches and discussions about the oe-core layer
> >	<openembedded-core at lists.openembedded.org>
> >Message-ID: <1331799594.18586.61.camel at ted>
> >Content-Type: text/plain; charset="UTF-8"
> >
> >On Thu, 2012-03-15 at 01:11 +0000, Daniel Lazzari wrote:
> >> Let me preface this by saying I'm running an older oe-core (Angstrom) so
> >this may be fixed in the latest, but if so, I'm hoping someone can point me at
> >the patch to fix it.
> >>
> >> I have a few recipes in our layer that need to generate proprietary packages
> >from ${D} after the do_package task has copied the files for its own devices.
> >To do this, I have a task like:
> >>
> >> do_create_foo() {
> >> 	#Generate foo package here
> >> 	foo_pkger ${D} ${DEPLOY_DIR}/foo/${MACHINE}
> >> }
> >> addtask create_foo after do_package before do_build
> >> do_create_foo[dirs] = "${DEPLOY_DIR}/foo/${MACHINE}"
> >>
> >> The problem is, when building any recipe that depends on this recipe,
> >> it reruns do_create_foo. This is especially problematic because we use
> >> rm_work, so often when it goes back to rerun do_create_foo, ${D} no
> >> longer exists. I checked and a stamp exists for the task.
> >>
> >> Anyone have any insight? Is anyone else seeing something like this?
> >
> >It looks like you're creating something machine specific since you're
> >placing it in ${MACHINE}. This effectively makes anything depending on
> >this task machine specific also.
> >
> >Cheers,
> >
> >Richard
> >
> 
> I finally found the answer to this in case anyone else runs into it.
> The rm_work class removes stamps if they are not in a case statement
> in that class. Once I added *do_create_foo* to the case statement, the
> stamp was left alone and everything is working again.

Ah, right. The other solution would be to cover this task with sstate,
see deploy.bbclass as an example.

Cheers,

Richard