Currently if a package in the DEPENDS list is modified, a package that depends on it does not get updated even if explicitly build E.g. when I just updated libexif and after that did a bitbake mythplugins (which has a DEPENDS on libexif) libexif got build but mythplugins did not get rebuild.
This is not really proper. E.g. if the lib changed a .h file the build of the using package could fail, but it could easily get unnoticed as one will only become aware of this when forcefully rebuilding that using package. I think we can do better by better exploiting the timestamp. E.g. what about doing it this way: If you build a package and the timestamp of e.g. do-install (or do-stage or another pass) of one of your DEPENDS packages is newer than your do-install (or another task) then your dependency is most likely newer, so you need a rebuild. (preceded with a clean to get rid of the old stuff). This should be added to the task list. Of course is is not as trivial as I sketch here. This whole game needs to be played recursively bottom up. So if A depends on B and B depends on C and C gets changed for whatever reason, then bitbake A should lead to rebuilding B first. A similar thing might also be needed for RDEPENDS. If you run time depend on a package that is newer than you are, it might also be that there are inconsistencies. How does this sound? I assume it will increase the workload of bitbake, but I feel this will lead to more stable packages. Your feedback is appreciated! Frans. _______________________________________________ Openembedded-devel mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
