| Summary: | "all" tasks don't affect all packages? | ||
|---|---|---|---|
| Product: | [Build System, Metadata & Runtime] BitBake | Reporter: | Jerrod Peach <peachj> |
| Component: | bitbake | Assignee: | Richard Purdie <richard.purdie> |
| Status: | RESOLVED NOTABUG | QA Contact: | |
| Severity: | normal | ||
| Priority: | Medium | CC: | poky.bs.watcher, poky.watcher, sgw |
| Version: | 1.3 | ||
| Target Milestone: | 1.4 | ||
| Hardware: | x86 | ||
| OS: | Multiple | ||
| Whiteboard: | |||
| OS type for building Yocto: | --- | Type of Regression: | --- |
| Verified: | Documentation change: | --- | |
|
Description
Jerrod Peach
2012-12-10 14:12:20 UTC
Its important to consider what "recrdeptask" means and there has been a bit of conflict over what exactly this means in bitbake. Taking: do_checkuriall[recrdeptask] = "do_checkuri" bitbake will look through the DEPENDS+RDEPENDS of the task and for each one, see if there is a do_checkuri task for the depedency. If it sees one, it will add a dependency on it. do_checkuriall[recrdeptask] = "do_checkuriall do_checkuri" will do the same thing but also look for and add dependencies on other do_checkuriall tasks. These in turn will have dependencies on their DEPENDS+RDEPENDS so the list is larger. This behaviour was chosen as the user can clearly select between the two different bahviours easily. Does this 100% match the previous behaviour bitbake sometimes had? No. The difference is "task dependencies" or 'tdepends'. Imagine do_something is a task after do_checkuri which has do_something[depends] = "somerecipe:do_xxx". Note that neither do_checkuri or do_checkuriall depend on this task, nor should they, it happens afterwards. Its these tasks which account for the difference you're seeing. The hard part comes if somerecipe has a do_checkuri task, should that be included in the dependecies? Right now, the answer is no, it isn't included and you can argue this both ways. The trouble is sometimes you want this behaviour and sometimes you definetely don't want it. It can trigger much more to get built than you would sometimes desire. Its also a pain to implement since you have to inject dependencies that are somewhere "up" the stack. Ultimately the solution is probably to add a new dependency type to bitbake and use this to signify when we really want *any* given task regardles of where the tdepends come in. Even then we need to carefully define the corner cases. So the current behaviour is likely intentional. It may not be the desired behaviour in every case. RP, It took me a while to understand your comment, but I think I get it now. I agree with your assessment, and noticed after more careful analysis that none of the "all" tasks I care about seem to be going AWOL on packages that I care about. If you don't have any new features you want to add based on this, I guess this can be closed because everything is functioning as designed? Kind regards, Jerrod I'm going to close this out as the system is working as designed. If anyone has a real world use case where there are problems, we can discuss this further. |