Re: [Bitbake-dev] Bitbake task dependency stamp handling

[Richard Purdie <rpurdie@rpsys.net>]

On Sun, 2007-01-07 at 20:23 +0100, Marcin Juszkiewicz wrote:
> Dnia niedziela, 7 stycznia 2007 19:54, Koen Kooi napisał:
> 
> > > If we move away from the digraph which isn't really needed anymore,
> > > taskData has the complete dependency tree available to it and the
> > > option of rebuilding the whole system if you recompile gtk becomes
> > > possible.
> > >
> > > At face value this sounds really useful. I'd guess that almost every
> > > OE developer would find it insanely annoying in practise though?
> >
> > Annoying, maybe, correct behaviour, yes. Option for local.conf?
> 
> It will be good thing. But I think that there must be kind of option to 
> tell which exactly package force other to be rebuilt. I would like to be 
> able to ignore situation where gcc packaging change introduce rebuild of 
> everything. But if gcc change and gtk+ will be also changed then I want 
> to do build which will rebuild all gtk+ dependend recipes.

As an illustration, changing gcc packaging can affect gtk+ due to shlibs
and package renaming. Its likely at the very least gtk+ would repackage
as would almost everything. 

> Having option in local.conf probably will be easier for bitbake parser 
> then providing list of recipes which force 'own childs' to be rebuilt.

Bitbake would work out the list of recipes itself, in fact it already
knows this (have a look at the output from bitbake trunk's -g option). 

I guess you mean defining the criteria for when to rebuild or not to
rebuild and this is hard :-/.

> I think that this is a place where we need some kind of UI which will be 
> able to request action from us (but rather on start of build then during 
> build - many of our builds goes without any interactive usage (nightly 
> runs etc).

Agreed and I'm trying to keep this in mind with the new UIs...

Cheers,

Richard