Re: Image recipes in Yocto 1.4 (dylan-9.0.0)

[Brian Karcz <briank@RUSSOUND.COM>]

Hi Paul,

Here is a little background of what is going on. I inherited a project that was implemented under and works with Edison. The project has two image recipes, abc-main.bb and abc-ramdisk.bb. The way the project builds under Edison, abc-main.bb has abc-ramdisk listed in the DEPENDS variable. Abc-main then has an image preprocess command that sneakily goes into the DEPLOY_DIR_IMAGE and retrieves the ramdisk image and inserts it into its own IMAGE_ROOTFS.

As I've been working on porting to the Dylan version of the build system, I found the whole issue with do_fetch and do_unpack not being run at all for images. I applied the fix you advised of to add a python function that removes the noexec flag for the two tasks. This apparently only works for one build of the image. I either need to do a "cleanall" on the image or bump the rev to get it to build again.

To simplify things, and remove the dependency between the main and ramdisk images, I started building just the ramdisk directly. Doing this I see the same behavior:
	Bitbake abc-ramdisk -c cleanall
	Bitbake abc-ramdisk			<--- succeeds
	Bitbake abc-ramdisk			<--- fails trying to operate on one the files in the SRC_URI

As I mentioned in the previous post. I'm using the rm_work directive in the local.conf file. Its interesting that the subsequent re-build doesn't determine that the WORKDIR needs to be repopulated. Another interesting note that might be of interest is that our LICENCE is defined to "XYZ" and issues the following warning, "WARNING: abc-ramdisk: No generic license file exists for: XYZ in any provider", in the first build that succeeds. When the second build is run the warning does not appear and the build jumps right to the do_rootfs task where it fails.

Thanks,
Brian 

-----Original Message-----
From: Paul Eggleton [mailto:paul.eggleton@linux.intel.com] 
Sent: Tuesday, July 16, 2013 1:30 PM
To: Brian Karcz
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] Image recipes in Yocto 1.4 (dylan-9.0.0)

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