Re: [PATCH] cooker.py: Remove explicit build targets from the ignored list

[Paul Eggleton <paul.eggleton@linux.intel.com>]

On Friday 31 May 2013 08:29:43 Richard Purdie wrote:
> On Tue, 2013-05-28 at 22:54 -0500, Mark Hatle wrote:
> > From: Peter Seebach <peter.seebach@windriver.com>
> > 
> > If something is in ASSUMED_PROVIDED, and a user tries to build it
> > explicitly, Nothing Happens. Bitbake just says it ran 0 out of 0
> > tasks. No diagnostics or explanations are offered.
> > 
> > In practice, the right thing is probably to assume that explicit
> > targets are intentional. So far as I can tell, cooker.buildTargets
> > is called only from the command line or from command.py, and both
> > cases seem to be explicit user actions.
> > 
> > Signed-off-by: Peter Seebach <peter.seebach@windriver.com>
> > Signed-off-by: Jeff Polk <jeff.polk@windriver.com>
> > 
> > Rename 'status' to 'recipecache' to match recent changes.
> > 
> > Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
> > ---
> > 
> >  lib/bb/cooker.py | 5 +++++
> >  1 file changed, 5 insertions(+)
> > 
> > diff --git a/lib/bb/cooker.py b/lib/bb/cooker.py
> > index 2ae3e9d..8f0e90c 100644
> > --- a/lib/bb/cooker.py
> > +++ b/lib/bb/cooker.py
> > 
> > @@ -1067,6 +1067,11 @@ class BBCooker:
> >          universe = ('universe' in targets)
> >          targets = self.checkPackages(targets)
> > 
> > +        # Explicitly disignore things that have been requested.
> > +        for target in targets:
> > +            if target in self.recipecache.ignored_dependencies:
> > +                self.recipecache.ignored_dependencies.remove(target)
> > +
> > 
> >          def buildTargetsIdle(server, rq, abort):
> >              if abort or self.state == state.stop:
> >                  rq.finish_runqueue(True)
> 
> I'm not sure this is the right thing to do, the reason being
> determinism. I don't expect different results for X in the different
> cases:
> 
> bitbake X Y
> 
> bitbake X
> 
> (assuming Y is ASSUME_PROVIDED)
> 
> For example, X will rebuild between these two commands since the sstate
> and task checksums will be different between the two. This really needs
> more thought to make a consistent user experience...

It seems to me the most consistent behaviour would be to just report a warning 
that Y is in ASSUME_PROVIDED and carry on building.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre