Quick question about OE-core/bitbake's re-building

Quick question about OE-core/bitbake's re-building

[Joel Fernandes]

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/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.

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

Re: Quick question about OE-core/bitbake's re-building

[Tyler Hall]

[-- Attachment #1: Type: text/plain, Size: 1087 bytes --]

On Sun, May 4, 2014 at 4:53 PM, Joel Fernandes <joelf@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.
>

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

[-- Attachment #2: Type: text/html, Size: 1585 bytes --]

Re: Quick question about OE-core/bitbake's re-building

[Joel Fernandes]

On 05/04/2014 04:52 PM, Tyler Hall wrote:
> On Sun, May 4, 2014 at 4:53 PM, Joel Fernandes <joelf@ti.com
> <mailto:joelf@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

Re: Quick question about OE-core/bitbake's re-building

[Burton, Ross]

On 5 May 2014 01:34, Joel Fernandes <joelf@ti.com> wrote:
> 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