[oe] BB_STAMP_POLICY

[Richard Purdie]

On Tue, 2008-06-03 at 00:09 +0200, Detlef Vollmann wrote:
> The biggest problem I see are silent breaks, because of changes in
> some configuration files that are not tracked by dependency checking.

I not 100% sure what you're getting at here but I'll try and follow this
to its logical conclusion.

If you change something in some recipe, say EXTRA_OECONF you then need
to force a rebuild of the recipe either by bumping PR, using the --force
option etc. to make the change take effect. This means package A would
rebuild and the way BB_STAMP_POLICY full/whitelist works means that
since A rebuilt, anything depending on A will also rebuild. So this case
is covered.

Perhaps you mean that you change some variable in say bitbake.conf and
you then don't know which recipes it may have an effect on. You
therefore don't know which to rebuild?

Bitbake can't know whether a given change in some conf file changes a
given package. What it can in theory tell is whether the some
conf/class/bb/inc file has changed or not since a given package was
built. We already have this cache logic in place but it currently has no
influence on stamp validity decisions. It would be possible to wire that
into the stamp logic so if you touch bitbake.conf anything which could
be influenced by that file (everything) would rebuild. If you touch a
class file like kernel.bbclass, just the kernel would rebuild (and
anything depending on it). Any change to local.conf would rebuild
everything.

For comparison note that your USE variables just cover the EXTRA_OECONF
variable. There are hundreds of other variables which can influence the
build and trying to build a definitive list of them would be difficult.
What makes EXTRA_OECONF special?

Cheers,

Richard