On Wed, 2010-01-13 at 15:24 -0800, C Michael Sundius wrote: > We've run into the problem where developers who are busily making > changes to their code, building it, testing it and then doing that all > over again and again are being bogged down because in one particular > use case, several dependent objects (from different recipes/packages) > are statically lined together into a single kernel module. > Unfortunately when one recipe is rebuilt, the dependant recipe (that > links all the modules together) is not: > > if A depends on (the staging output of) B, and B is rebuilt, A is not > (automatically rebuilt). > > The conventional wisdom on the OE list is that "this is not supported > though it would be nice to have" > > In reading thru the bitbake-dev archive I came accross this posting: > > https://lists.berlios.de/pipermail/bitbake-dev/2008-February/000385.html > > in which Richard Purdie seems to have resolved this issue. though, I > never saw a corresponding formal patch. > > 1) Did this code make it into Bitbake somehow? > 2) If so how to I make use of it. > 3) if not does anyone have any comments on how to resolve this > problem.
You might want to look at BB_STAMP_POLICY = "full" or maybe "whitelist". These will mean that when any dependency changes a given package rebuilds. "whitelist" mode uses BB_STAMP_WHITELIST to only handle full dependencies on a subset of packages if I recall correctly. > I'm trying to come up to speed on how bitbake works internally, but > its slow going, if anyone could offer a hand to give me a clue where > to start, I'd be eternally grateful. The above is handled in runqueue.py. Cheers, Richard _______________________________________________ Bitbake-dev mailing list [email protected] https://lists.berlios.de/mailman/listinfo/bitbake-dev
