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

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

[Mark Hatle]

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)
-- 
1.8.1.2.545.g2f19ada

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

[Richard Purdie]

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...

Cheers,

Richard

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

[Paul Eggleton]

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

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

[Peter Seebach]

On Fri, 31 May 2013 08:29:43 +0100
Richard Purdie <richard.purdie@linuxfoundation.org> wrote:

> 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...

Hmm. I don't *normally* expect different results, but might if the first one
produced a diagnostic: "Warning: Y is in ASSUME_PROVIDED. Rebuilding Y will
produce different versions of anything which depends on Y."

Paul's suggestion that we just print a diagnostic for anything which is in
both targets and ASSUME_PROVIDED might well do, too. Although it might be nice
to have a reasonably straight forward command-line way to express "no, really,
I want you to build Y" which doesn't require config file action.

-s
-- 
Listen, get this.  Nobody with a good compiler needs to be justified.

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

[Richard Purdie]

On Fri, 2013-05-31 at 11:32 -0500, Peter Seebach wrote:
> On Fri, 31 May 2013 08:29:43 +0100
> Richard Purdie <richard.purdie@linuxfoundation.org> wrote:
> 
> > 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...
> 
> Hmm. I don't *normally* expect different results, but might if the first one
> produced a diagnostic: "Warning: Y is in ASSUME_PROVIDED. Rebuilding Y will
> produce different versions of anything which depends on Y."
> 
> Paul's suggestion that we just print a diagnostic for anything which is in
> both targets and ASSUME_PROVIDED might well do, too.

I'll certainly take a patch for that.

>  Although it might be nice
> to have a reasonably straight forward command-line way to express "no, really,
> I want you to build Y" which doesn't require config file action.

Agreed, however we need to get the user interaction right here.
Currently the user doesn't expect for example that the configuration
files change from under them. In future this may well be something we do
(along with informing the user what happened). Users tend not to read
information though :/.

Cheers,

Richard