On Tue, Mar 10, 2020 at 11:37:55AM +0000, Richard Purdie wrote:
> On Tue, 2020-03-10 at 11:33 +0000, Mikko.Rapeli@... wrote:
> > On Fri, Feb 28, 2020 at 11:25:59PM +0000, Richard Purdie wrote:
> > > On Fri, 2020-02-28 at 22:51 +0000, Sean McKay wrote:
> > > > This is probably a fairly short question (I hope):
> > > > I’m working on a branch based on zeus. I found a bug in the way that
> > > > one of our recipes was handling something during do_configure (which
> > > > caused an error to pop up in a do_compile task). When I modified the
> > > > do_configure task (do_configure_append, actually) to behave properly
> > > > (which involved changing the actual commands run in that function)
> > > > and reran bitbake -c compile <recipe>, the do_configure task wasn’t
> > > > rerun despite the change to the function’s code.
> > > > 
> > > > Is it safe to assume this means we’ve done something to mess up the
> > > > way our system is processing things? Or is that expected behavior
> > >
> > > Its not expected behaviour and yes, it sounds like something is messed
> > > up...
> >
> > This is what I've come to expect with yocto 2.0 jethro, 2.5 sumo and
> > 3.0 zeus.
> >
> > That's why I always write:
> >
> > $ bitbake -c clean recipe && bitbake -c cleansstate && bitbake -c compile recipe
> >
> > when debugging changes in recipes to_compile and other dependent tasks.
> > I'm also cleaning up sstate to be sure it's not corrupt or filled with
> > somehow bad data.
>
> This is bad and shouldn't be happening. Can anyone provide some
> examples I can look at?
>
> You shouldn't ever need to run cleansstate in particular. If you have
> to, there is another underlying bug that should get fixed.

Sadly custom bbclasses and BSP layers have this effect on my builds and I
can't fully trust local incremental builds. Hence I clean sstate cache
often.

-Mikko