[OE-core] [PATCH] Revert "bitbake.conf: don't remove WARN_QA and ERROR_QA from hashes"

Paul Eggleton paul.eggleton at linux.intel.com
Fri Feb 6 16:29:28 UTC 2015


On Friday 06 February 2015 13:53:42 Otavio Salvador wrote:
> On Fri, Feb 6, 2015 at 1:13 PM, Richard Purdie
> 
> <richard.purdie at linuxfoundation.org> wrote:
> > On Fri, 2015-02-06 at 16:02 +0100, Martin Jansa wrote:
> >> On Fri, Feb 06, 2015 at 12:21:23PM -0200, Otavio Salvador wrote:
> >> > On Fri, Feb 6, 2015 at 12:18 PM, Burton, Ross <ross.burton at intel.com> 
wrote:
> >> > > On 6 February 2015 at 14:10, Otavio Salvador
> >> > > <otavio at ossystems.com.br>
> >> > > 
> >> > > wrote:
> >> > >> I think they should re-run. Otherwise we can end having errors and
> >> > >> QA
> >> > >> issues unnoticed until a full rebuild.
> >> > > 
> >> > > That was the state of things until my original patch last week.  The
> >> > > patch
> >> > > had the side-effect that changing QA tasks causing *everything* to
> >> > > rebuild.
> >> > > I'm really not sure that's a good solution.
> >> > 
> >> > If someone adds a QA tasks it is because it matters. In this case we
> >> > ought to have it in an immediate effect so it does makes sense to
> >> > rerun everything.
> >> > 
> >> > I know it is bad from build time point of view but predictability and
> >> > correctness is more important from my point of view.
> >> 
> >> Agreed, especially when someone decides to make something fatal it
> >> should highlight all failing recipes before it's enabled in "official"
> >> build instead of sneaking the failures one-by-one as sstate is being
> >> invalidated by other changes.
> > 
> > Thinking about this from the other angle. Should someone having a
> > different set of WARN/ERROR local settings mean they don't reuse sstate?
> 
> It should be checked against the different setting. If the price for
> it is sstate invalidness, so be it.

I honestly don't think this is right. The value of this variable does not 
belong in the signature - it does not affect the output of do_configure.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre



More information about the Openembedded-core mailing list