[bitbake-devel] bitbake clean / cleanall / cleansstate not working

[Purcareata Bogdan-B43198]

On 4/22/2013 2:05 PM, Paul Eggleton wrote:
> On Monday 22 April 2013 09:42:07 Purcareata Bogdan-B43198 wrote:
>> Richard Purdie wrote:
>>> What exactly are you trying to clean? The above messages say it ran 1, 2
>>> or 3 tasks and they all succeeded.
>> In my example, "gcc" can be replaced with any package provided by the Yocto
>> recipes. The problem is that nothing is being run - "0 didn't need to be
>> rerun " - so the built package is never cleaned. This issue is present when
>> running all clean commands - clean, cleanall, cleansstate.
> "0 didn't need to be rerun" does not mean nothing was done - it means the
> opposite. The number reported here is the number of tasks that were able to be
> restored from shared state - none (0) in this case because this is not
> applicable to the clean* tasks.
>
> Other than the message above, how are you determining that these tasks are not
> doing anything?

Thank you for the fast reply!

I've run some more tests and found some new stuff.

I'm running this:
     bitbake <package>
     bitbake -c cleanall <package>
     bitbake <package>

My expected result was that, at the second run of bitbake <package>, the 
whole package will be built again starting from fetch. While this is 
true for packages such as gcc or busybox, it's not true for the lxc 
package - this one starts from do_populate_sysroot (or somewhere near, I 
can't seem to tell since it's running very fast). I discovered this 
while developing some patches for the lxc recipe. I was hoping to see 
the functionality applied after clean and build, but it was not there.

When I saw "0 didn't need to be rerun " after bitbake cleanall, I 
thought it didn't run anything - now I understand what it means. I 
noticed this behavior for other packages as well, so I didn't bother to 
build the packages after clean, since I thought cleaning was the problem.

Do you think this behavior is recipe dependent?

>
>>> Keep in mind there are several "gcc" components such as gcc-cross,
>>> gcc-cross-initial and so on. "gcc" is the one used on target.
>> Do you think that a certain package can't be cleaned because of its
>> dependencies?
> No, that's very unlikely to be the case.
>
> Cheers,
> Paul
>