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 _______________________________________________ Bitbake-dev mailing list [email protected] https://lists.berlios.de/mailman/listinfo/bitbake-dev
