On 05/04/2014 04:52 PM, Tyler Hall wrote: > On Sun, May 4, 2014 at 4:53 PM, Joel Fernandes <jo...@ti.com > <mailto:jo...@ti.com>> wrote: > > How does it figure out when it needs to rebuild a package? > > > Bitbake generates hashes for every task that are based on the data that > will be used when running the task. This includes the body of the task > function, any variables it references, checksums of required files, and > hashes of tasks it depends on. This data is stored for each task in > $BUILDDIR/tmp/stamps. The task will re-run if a matching sigdata file > does not exist in the stamps directory. You can run bitbake-dumpsig on a > sigdata file to see what metadata changes will cause the task to rebuild. > > For example if I modify the file: > ../meta/recipes-core/systemd/systemd-serialgetty/serial-getty@.service > > Does it track the modification time to know it needs to rebuild > "systemd-serialgetty"? > > Because doing such a modification didn't cause it to rebuild. >
Thanks for your reply, that was helpful. > The modification time won't trigger a rebuild since the contents hash > the same. Changing the contents of the file should trigger a rebuild, > though. Makes sense. That's what I observed. However one thing, is the updates don't happen if you revert the changes back to what it used to be in an earlier revision. For example if I make changes such that task hash is now X Then I build, and its called r0.0. Then I make some more changes such that the hash is now Y And it becomes r0.1. Then after some more changes, it becomes X. Now instead of rebuilding and calling it r0.2, the rebuild doesn't happen. I wonder if this is the right thing, or the updates should continue to roll. -Joel -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
