4 ms·
I concur with your technical argument, except for the trust of what's being built. I have repeatedly found the shared state cache to be the achilles heel of my
by ephaeton 6y ago
I concur with your technical argument, except for the trust of what's being built. I have repeatedly found the shared state cache to be the achilles heel of my builds. You never want to have a false-positive hit in your cache, yet yocto has repeatedly bit me with that. I have had instances where bitbake claimed it was done, just to find wrong or missing artifacts in my image. Cleaning and rebuilding from scratch is a continuous exercise that's IME sadly necessary. ...let alone letting others use my build directories!
I accept yocto's right to exist, but I'm far from being happy for using it.
- fullstop 6y agoI don't want to be the person who says "you're doing it wrong", but you probably are doing something wrong. I've been using this for quite a while and have never had to clean the world to get things straightened out, or had a false positive in the cache. One thing that I had to do, however, was run bitbake-hashserv when running the shared state cache. Even so, this was because I was getting cache misses. If I may ask, what are you doing when it claims to be done but things aren't in a good state? If you're deleting files / directories manually instead of using bitbake commands you're going to have a bad time.
- rcxdude 6y agoI've had similar issues. It's rare but a nightmare to debug when it happens. One thing which consistently caused problems was OOM errors on compilers (fairly easy to encounter during a parallel yocto build). This was suprisingly effective at poisoning the state of the system (I'm not sure why this compared to any other failure was so problematic).