[yocto] Image recipes in Yocto 1.4 (dylan-9.0.0)

[Paul Eggleton]

Hi Brian,

Sorry this message got lost in my inbox.

On Monday 24 June 2013 16:22:27 Brian Karcz wrote:
> > Paul Eggleton wrote:
> > > Brian Karcz wrote:
> > > Is there a way to stop this optimization and have the image build 
> > > populate the work directory as it has in the past?
> > 
> > You should be able to do this in your image recipe:
> > 
> > python () {
> >         d.delVarFlag("do_fetch", "noexec")
> >         d.delVarFlag("do_unpack", "noexec") 
> > }
>
> That was what I needed to get my build(s) moving forward. It has brought me
> to a follow-up question. The image in question (a ramdisk image) is being
> built as a dependency of a larger image build. When I rebuild the parent
> image, bitbake believes the child image needs to be rebuilt, but when this
> occurs, do_fetch and do_unpack once again don't get executed and my build
> fails as before when it jumps straight to do_rootfs with an empty work
> directory. Upon seeing this, I attempted to re-build the child image from
> its own recipe, without trying to build the parent, and the same behavior
> occurs.
> 
> I was considering adding the child image to RM_WORK_EXCLUDE in local.conf,
> but that didn't seem intuitive to the problem. 

So you are using rm_work? If you are I don't think RM_WORK_EXCLUDE will really 
help.

Just to confirm, you're not referring to the WORKDIR of one recipe within the 
other are you? Also, how are you setting up the dependency relationship 
between the images?

> I would think bitbake would do nothing since nothing has changed, or the
> required tasks would be executed, but I wouldn't think telling the last
> build to leave the work area would be the fix.
> 
> Do have any thoughts on making this work past a single build?

So I haven't tested this exact configuration; it's possible that bitbake is 
eliminating a dependency based on the task being marked as "noexec", but I 
wouldn't have thought so.

Cheers,
Paul

PS: please keep replies on the mailing list. Thanks.

-- 

Paul Eggleton
Intel Open Source Technology Centre