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

[Paul Eggleton]

On Wednesday 20 June 2012 09:55:04 Björn Stenberg wrote:
> Paul Eggleton wrote:
> > 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.
> 
> I agree with that.
> 
> My concern is based on the fact that people (including myself) don't fully
> know all the details of how bitbake works, and tend to make assumptions
> based on other build systems they know, such as simple Makefiles.
> 
> I think the fact that bitbake sometime works differently means we should be
> extra careful about not playing into devlelopers' assumptions. The bitbake
> option --force sounds rather similar to make's --always-make, especially
> when it is described as: "force run of specified cmd, regardless of stamp
> status". 

I've not used this option with make before, so I tried it with the following 
trivial Makefile:

------------- snip --------------
b:
        touch b

a: b
        touch a
------------- snip --------------

If I run "make a" it of course runs "touch b" then "touch a". Then I run "make 
--always-make b", it runs "touch b" which is what you expect. However, if I 
subsequently run "make a" it does a "touch a" again - the dependency b has 
changed, so it recognises it needs to rebuild a. This looks to me to be 
exactly the same as the new proposed behaviour of -f in bitbake. The only 
wrinkle in external behaviour is that "make --always-make a" runs both "touch 
b" and "touch a"; this would be difficult for us to replicate in bitbake and I'm 
not sure it would be particularly useful. In any case it appears to me that if 
we're moving anywhere, we're at least moving in the direction of behaving more 
like make rather than less like it, would you agree?

> If we were to call it something different instead, like -t/--taint, this
> would avoid some assumptions about its behaviour and make it more clear
> that the output will be different even if the input is the same.
> 
> Sure, it's not a major issue. But I'm fairly confident that if we keep the
> option name but change its behaviour, I am going to have to explain more
> than once to developers not following this list or the commit logs why -f
> does not do what they think (even though one can argue it never did). I'd
> rather they discover up front that -f is deprecated and that they should
> look up a new option instead.

This is a change in established behaviour, yes, and all changes in behaviour 
of existing functionality come with a potential cost in terms of breaking 
existing user assumptions. It's worth pointing out though that bitbake's 
behaviour with regard to how it handles building after changes have been made 
has already changed quite significantly recently with the introduction and 
extension of shared state - it is now the case that if you make almost any 
change to the recipe and/or files it points to, the sstate signature changes 
and the task (plus all dependent tasks) will be rebuilt if called for. IMHO, 
this makes the change to -f make more sense - we're remaining consistent with 
the way the rest of the build system now works.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre