What is the right way to force rebuilds of dependencies in bitbake?

[Javi Roman]

On Tue, Aug 26, 2008 at 5:53 AM, Lewis Girod <girod at nms.csail.mit.edu> wrote:
> Hi,
>
> I am using bitbake to build images for a Gumstix.
>
> Their setup has a .conf file that sets preferred versions for things like
> the kernel; I used this to choose a different version than standard, and
> this worked.  Later, I wanted to switch back to the original version, but
> although the right version built, it was still pulling in modules from the
> other version.
>
> Based on info on the web, etc, I tried forcing a rebuild of various tasks
> and the main image, to no avail, e.g.
>
>   bitbake -f -c clean task-base-gumstix
>   bitbake -f -c clean gumstix-basic-image
>
>   bitbake -f -c rebuild task-base-gumstix
>   bitbake -f -c rebuild gumstix-basic-image
>
> I ended up just using the sledgehammer and deleting the tmp directory... :(
>
> My question is this:  what is the correct principle to apply when rebuilding
> parts of an image?
> It seems that rebuilding at the top level won't necessarily rebuild stuff
> that has changed.
> How can I know what to rebuild?  Is there a way to rebuild everything above
> the toolchain (kernel, userspace, image)?
> I don't have a good understanding of how this works so my solutions so far
> have been ad-hoc and trial and error.
> If someone could help me get the right model in mind, that would be great!
>
> BTW, openembedded is a really nice system.. a bit of a learning curve though
> :)
>
> Lewis
>

The rootfs process pulls the latest ipk files from the
tmp/deploy/.../ipk/.. directory to create the rootfs. You can clean
manually kernel and modules ipk files from deploy directory, and then
rebuild your rootfs.


-- 
Javi Roman