Quick question about OE-core/bitbake's re-building
Hi,
How does it figure out when it needs to rebuild a package?
For example if I modify the file:
../meta/recipes-core/systemd/systemd-serialgetty/[email protected]
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.
Even if I modify the recipe by simply opening it and writing to it, it doesn't do any rebuild of the recipe. How is it normally supposed to work?
I have PRSERV turned on, I'm hoping that any modification to the recipe itself or the files it installs should be enough to rebuild. So far, the rebuild doesn't always happen.
thanks,
-Joel
Quoted 2 lines · Joel Fernandes
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:
Quoted 7 lines
../meta/recipes-core/systemd/systemd-serialgetty/[email protected]
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.
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.
-Tyler
Quoted 14 lines · Tyler Hall
On Sun, May 4, 2014 at 4:53 PM, Joel Fernandes <[email protected] <mailto:[email protected]>> 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.
Quoted 8 lines
For example if I modify the file:
../meta/recipes-core/systemd/systemd-serialgetty/[email protected]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.
Quoted 3 lines
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
Quoted 11 lines · Joel Fernandes
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.
So the hash that Joel refers to is used as a key in the "sstate cache", and the build packages are cached in there. When you revert the package back to X instead of having to do a rebuild, it can simply extract the relevant file from the cache.
(you can verify this by reading the cooker log of the build)
Ross