| Summary: | Confusing error message if build/tmp/deploy is deleted between runs | ||
|---|---|---|---|
| Product: | [Build System, Metadata & Runtime] BitBake | Reporter: | Evadeflow <evadeflow> |
| Component: | bitbake | Assignee: | Richard Purdie <richard.purdie> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | Low | CC: | poky.bs.watcher, poky.watcher, sgw |
| Version: | unspecified | ||
| Target Milestone: | 1.4 | ||
| Hardware: | x86 | ||
| OS: | Multiple | ||
| Whiteboard: | |||
| OS type for building Yocto: | --- | Type of Regression: | --- |
| Verified: | Documentation change: | --- | |
|
Description
Evadeflow
2012-10-20 18:46:46 UTC
(In reply to comment #0) > If I delete the tmp/deploy folder from the build directory and re-run > bitbake, it fails with a ton of scary output (see below). > > Steps to reproduce: > > > % source oe-init-build-env > > % bitbake -c rootfs core-image-minimal > > % rm -rf tmp/deploy > > % bitbake -c rootfs core-image-minimal > > Setting aside the question of why I did this (ANSWER: I'm a n00b and don't > know any better), I'm wondering: > > 1. Can bitbake really not recover from this? If not: > 2. Can the error message below be improved? The build system is an extremely complex piece of code which has many different demands being placed on it which include some that cover performance. When you run a bitbake command, its not possible to perform an integrity check on the whole system and ensure files are consistent. The problem you're running into is that the stamps directory says one thing (tmp/delpoy/ipk is full of .ipk files) yet you went and changed that behind the system's back. There are 101 ways where you can delete files and cause the system to break in interesting ways. The answer is more about encouraging people *not to delete files from under bitbake* since I don't think it would be possible to validate every possibile combination, its simply not supported and if we did do it, we'd kill performance. FWIW we do support removing the whole of tmp/ and the system will reuse sstate components to rebuild it. Whilst I dislike it, we have have "rm_work" as a mechanism for clearing space during builds. (In reply to comment #1) > The build system is an extremely complex piece of code which has many > different demands being placed on it... > > There are 101 ways where you can delete files and cause the system to break > in interesting ways. That's fair. I'm learning just how difficult it is to solve the problems that bitbake (+Yocto) is intended to solve. The fact that it solves them at *all* is increasingly impressive to me. Up to now, I've only worked with LTIB and LDAT; they're not any easier to use, and they won't build an entire cross toolchain for you(!) Yocto is pretty awesome, really. > FWIW we do support removing the whole of tmp/ and the system will reuse > sstate components to rebuild it. I knew this, and that's actually what made me try deleting only tmp/deploy. I was thinking it would behave like 'make', where removing an object that another depends on will cause that object to be regenerated. This doesn't seem like a crazy expectation, but I can see how trying to protect users from every single 'weird' thing they might try would be intractable. I'm only mentioning this particular item in case it's helpful in identifying trouble spots for new users. I won't be at all offended if you want to close this ticket. (That goes for any tickets I open while I'm still in my 'stumbling around' phase with Yocto. I'm hoping the feedback will be helfpul, but I understand it's not realistic to solve every little problem a new user might encounter.) I've put a patch out which makes the system error if it can't find any packages. I think that is as close as we can get to resolving this. |