[oe] [rfc] stamp removal

[Richard Purdie]

Hi,

On Tue, 2007-09-11 at 09:33 +0200, pHilipp Zabel wrote:
> I was wondering whether it would be a nice touch to have tasks that
> remove other task's results remove the other tasks's stamps, too.
> Example: do_package removes the image dir, so it could remove the
> do_install stamp. do_rm_work removes the complete workdir, so it could
> remove the do_fetch ... do_package stamps, etc.

You could add the code but it won't do what you want. Bitbake checks the
timestamps of task dependencies before running a task. For example
"compile" checks the stamps of "patch", "configure", "unpack" etc. Its
also worth noting it checks the order of the timestamps and any
dependencies have to have earlier timestamps.

If you remove or touch a stamp, bitbake will want to run the subsequent
tasks again before accepting that tasks timestamp as valid.

Whilst this behaviour is currently limited to package boundaries, in
future its planned to (optionally) make it system wide so if you rebuild
gtk, anything depending on gtk will magically rebuild too.

We could try and change the behaviours but it needs more thought than
simply deleting stamps and the bitbake core will need changes.

> I'm often running into errors because bitbake makes certain
> assumptions about what is in the work dir just by looking at the
> stamps, and currently stamps and workdir state are not always in sync.
> Example actions are doing one of the configure/compile/package_write
> steps when I forgot that rm_work already had kicked in or doing
> package_write to repackage after code changes (currently I manually
> have to do_install, too).

Personally, I want to see tasks "just work". Ignoring rm_work for a
minute, I've recently committed fixes (making sure the image directory
was clean) so the install task could rerun with less problems. Next, I'd
like to see do_package stop moving files around and just copy them. If
it does that, each task should be rerunable without strange effects. You
can currently rerun package_write_ipk/deb and package_write, its just
do_package thats problematic due to the file moves as far as I know.

Coming back to rm_work, its a separate problem and I'm not sure how to
address it.

Cheers,

Richard