On Fri, 2006-05-26 at 22:22 +0200, Rene Wagner wrote: > Not entirely, I'm afraid. Apparently the RDEPENDS inference code is to > some extent always active (I haven't managed to take the time to look > into the code yet). I talked to Richard about this a while ago and as > I understand it there's no quick fix/workaround for it. > > On a clean build bitbake will spit out a number of error messages due to > not being able to read not-yet written files containing kernel > version information (unless you apply a patch to base.bbclass that > doesn't look right to me).
Its not the RDEPENDS inference code but the cache speedup although both sets of code have problems with this. To clarify, bitbake now always looks at the RDEPENDS variable when working out what to build (for caching), even if it doesn't use the value at a later date. There are various reasons that result in this being the most efficient thing to do. Old versions of the OE metadata used to rely on RDEPENDS not being accessed until after a given package's DEPENDS had been built. As far as I'm concerned this is a bug in the OE metadata and OE never had the right to assume that. The bug has been worked around in .dev and in .oz354x and is pending a better fix. I'm convinced we can't allow key variables like this to depend on the previous build dependencies as taking it to an extreme, it means things like parallel bitbake builds are not possible. As I think we need to keep that option available, we need to find an alternative solution, or use the workaround. > Also, it seems there are cases of the dependency handling not yielding > the exact same results as before, but I haven't had the time to check > that properly yet. I'd be interested in the results. As previously stated, there are no known bitbake regressions and if there are any, I'll do my best to address them, as I suspect will zecke. Note that the build order could have changed but it should still respect the variables as defined. Regards, Richard _______________________________________________ Oe mailing list [email protected] https://www.handhelds.org/mailman/listinfo/oe
