[oe] [RFD] increased dependency checking

[Chris Larson]

I'm pretty sure you can set BB_STAMP_POLICY to something other than perfile
to get the behavior you're talking about here.  We also chose the current
behavior over the one you propose intentionally when writing bitbake, fyi.
 It's not an oversight.  I can see an argument for changing the default, to
prefer build reliability over performance, but very few changes to a dep
require that the things that  dep on it be rebuilt, generally only ABI
changes.  Hence, the variable to control the behavior.

On Sat, Aug 28, 2010 at 1:23 AM, Frans Meulenbroeks <
fransmeulenbroeks at gmail.com> wrote:

> Currently if a package in the DEPENDS list is modified, a package that
> depends on it does not get updated even if explicitly build
> E.g. when I just updated libexif and after that did a bitbake
> mythplugins (which has a DEPENDS on libexif) libexif got build but
> mythplugins did not get rebuild.
>
> This is not really proper. E.g. if the lib changed a .h file the build
> of the using package could fail, but it could easily get unnoticed as
> one will only become aware of this when forcefully rebuilding that
> using package.
>
> I think we can do better by better exploiting the timestamp.
> E.g. what about doing it this way:
>
> If you build a package and the timestamp of e.g. do-install  (or
> do-stage or another pass) of one of your DEPENDS packages is newer
> than your do-install (or another task) then your dependency is most
> likely newer, so you need a rebuild. (preceded with a clean to get rid
> of the old stuff). This should be added to the task list.
>
> Of course is is not as trivial as I sketch here.
> This whole game needs to be played recursively bottom up.
> So if A depends on B and B depends on C and C gets changed for
> whatever reason, then bitbake A should lead to rebuilding B first.
>
> A similar thing might also be needed for RDEPENDS.
> If you run time depend on a package that is newer than you are, it
> might also be that there are inconsistencies.
>
> How does this sound? I assume it will increase the workload of
> bitbake, but I feel this will lead to more stable packages.
> Your feedback is appreciated!
>
> Frans.
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>



-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics