[oe] [Bitbake-dev] Bitbake task dependency stamp handling
Richard Purdie
rpurdie at rpsys.net
Mon Jan 8 00:08:42 UTC 2007
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
More information about the Openembedded-devel
mailing list