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.eggle...@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
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
