On Tue, Mar 10, 2020 at 11:37:55AM +0000, Richard Purdie wrote:
On Tue, 2020-03-10 at 11:33 +0000, Mikko.Rapeli@bmw.de wrote:
On Fri, Feb 28, 2020 at 11:25:59PM +0000, Richard Purdie wrote:This is bad and shouldn't be happening. Can anyone provide some
On Fri, 2020-02-28 at 22:51 +0000, Sean McKay wrote:This is what I've come to expect with yocto 2.0 jethro, 2.5 sumo and
This is probably a fairly short question (I hope):Its not expected behaviour and yes, it sounds like something is messed
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
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.
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