Re: [PATCH 1/2] bitbake: ensure -f causes dependent tasks to be re-run

[Paul Eggleton <paul.eggleton@linux.intel.com>]

On Tuesday 19 June 2012 21:35:39 Björn Stenberg wrote:
> Paul Eggleton wrote:
> > If -f is specified, force dependent tasks to be re-run next time. This
> > works by changing the force behaviour so that instead of deleting the
> > task's stamp, we write a "taint" file into the stamps directory, which
> > will alter the taskhash randomly and thus trigger the task to re-run
> 
> I'm concerned about calling this -f/--force. I don't think I'm alone in
> interpreting -f / --force as "run all commands, even if the dependencies
> say we don't need to".

Well, what it used to do was just cause the specified task to be run even if 
there is a stamp recording that it was already done; dependencies don't come 
into it (although perhaps you meant stamps?)

> I would expect the same output as the first time,
> with the same sstate checksum.

So my assumption is -f is most often used for the purpose of manually forcing 
a recompile after you have made modifications to the already extracted source 
code under the workdir. If that is the case, there are two consequences as I 
see it:

 * When Bitbake next checks whether you want to run dependent tasks, given 
that the output of the task almost certainly changed due to your modifications, 
you would want those dependent tasks to be re-run again also. i.e. if you've 
forced a compile, you would expect for the results to be installed and 
packaged when you next ask for the do_install / do_package tasks to run.

 * You don't really want those modifications going into the sstate package that 
effectively claims to be produced from inputs that only come from the metadata. 
Now, obviously it doesn't physically prevent you from ever getting modified 
data into an sstate package with the same signature, but it makes it less 
likely.

My question would be, are you using -f for something different or do you 
disagree with one or both of the consequences above?

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre