Bug 2256

So many other steps seem to invalidate the later steps so bitbake knows to rerun them. Is this just a matter of killing the stamp files for the do_compile during the do_menuconfig task?

Sadly not. The issue is that bitbake has no knowledge that -c menuconfig invalidates the configuration. It sees the same sstate hash for populate_sysroot so "accelerates" the build.

I suspect we're going to have to set some kind of new "no sstate" flag against the recipe so it doesn't touch sstate even if the checksum would apparently match.

Of course the next issue is you could "corrupt" a sstate cache this way if generated sstate code was then shared.

I guess the above "no sstate" flag would need to disable sstate generation too.

RP, I'm not sure I fully follow what you're suggesting. You aren't suggesting we disable all sstate usage by linux kernel recipes are you?

(In reply to comment #3)
> RP, I'm not sure I fully follow what you're suggesting. You aren't suggesting
> we disable all sstate usage by linux kernel recipes are you?

Once menuconfig was used.

Release Note:

If you change the config during a build, bitbake may not detect the change and will not rebuild the kernel. After changing the config, be sure to force a kernel recompile:

$ bitbake virtual/kernel -c menuconfig
$ bitbake virtual/kernel -c compile -f; bitbake virtual/kernel

*** Bug 2350 has been marked as a duplicate of this bug. ***

Note that the workaround in Comment 5 is insufficient and should read:

Due to an issue with sstate and the menuconfig task for recipes such as
Linux kernels and busybox, it is necessary to clean sstate prior to
re-configuring and rebuilding the recipe. For example:

$ bitbake virtual/kernel -c cleansstate
$ bitbake virtual/kernel -c menuconfig
$ bitbake virtual/kernel -c compile -f; bitbake virtual/kernel

Unfortunately this does not only apply to menuconfig.

The following scenario also does not work
bitbake virtual/kernel
modify a kernel source file
bitbake -ccompile -f virtual/kernel
bitbake virtual/kernel
The latter does not run do_install

This is on ppc 

I tried the cleansstate solution, as suggested by Darren in comment 7 but unfortunately cleansstate implies clean so it removes the whole tree (including the modified file).

Unfortunately this does not only apply to menuconfig.

The following scenario also does not work
bitbake virtual/kernel
modify a kernel source file
bitbake -ccompile -f virtual/kernel
bitbake virtual/kernel
The latter does not run do_install

This is on ppc 

I tried the cleansstate solution, as suggested by Darren in comment 7 but unfortunately cleansstate implies clean so it removes the whole tree (including the modified file).

I've sent out some patches to fix this - one as part of a series to bitbake-devel and another to the oe-core list.

While running the examples in the YP Development Manual I hit this bug against the YP 1.1.2 version.  This is surprising as it was not there for 1.1.1 and had originally surfaced during YP 1.2.

Fix merged to master in revisions 5bd11a9bf329217f312076f347b045b5c09f19b2 and 66123b92557a7c1d63c29e90d9a8ba4ef146fc8a. Note that to work this does require that you use fully signature based stamps (i.e. BB_SIGNATURE_HANDLER = "OEBasicHash"), which is the default in poky.

Verified that the sequence in the bug description is working as expected

Commit: 3309cf42d314f0a26079a11836c6b9b9bb5f253e

Hi,

Unless I am doing something wrong, this bug is still present in Yocto 1.7. The described sequence in the bug report still produces a kernel with the old configuration and the workarround in comment 5 doesn't work. A workarround that seems to work is the following:

bitbake -c menuconfig linux-yocto
bitbake -C compile linux-yocto (notice the upper case C option)

Feel free to ask me if you need more informations.

Regards