[PATCH 0/1] die if a .bbappend file matches no existing .bb recipe

[PATCH 0/1] die if a .bbappend file matches no existing .bb recipe

[Dexuan Cui]

Please review the patch.

The following changes since commit 2152759b50cc3acc96ee57b242e0b896e65f5e93:

  sanity.bbclass: only run check_pseudo_wrapper for bitbake (2011-06-19 19:50:46 +0800)

are available in the git repository at:
  git://git.pokylinux.org/poky-contrib dcui/bb
  http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=dcui/bb

Dexuan Cui (1):
  die if a .bbappend file matches no existing .bb recipe

 bitbake/bin/bitbake-layers |   19 -------------------
 bitbake/lib/bb/cooker.py   |   16 ++++++++++++++++
 2 files changed, 16 insertions(+), 19 deletions(-)

[PATCH 1/1] die if a .bbappend file matches no existing .bb recipe

[Dexuan Cui]

This patch moves the logic of show_appends_with_no_recipes from bitbake-layers
into bitbake, and makes the script die with a fatal error message printed.

Signed-off-by: Dexuan Cui <dexuan.cui@intel.com>
---
 bitbake/bin/bitbake-layers |   19 -------------------
 bitbake/lib/bb/cooker.py   |   16 ++++++++++++++++
 2 files changed, 16 insertions(+), 19 deletions(-)

diff --git a/bitbake/bin/bitbake-layers b/bitbake/bin/bitbake-layers
index 6b5ad5a..6178513 100755
--- a/bitbake/bin/bitbake-layers
+++ b/bitbake/bin/bitbake-layers
@@ -85,8 +85,6 @@ class Commands(cmd.Cmd):
 
         self.show_appends_for_skipped()
 
-        self.show_appends_with_no_recipes()
-
     def show_appends_for_pn(self, pn):
         filenames = self.cooker_data.pkg_pn[pn]
 
@@ -133,23 +131,6 @@ class Commands(cmd.Cmd):
                 notappended.add(basename)
         return appended, notappended
 
-    def show_appends_with_no_recipes(self):
-        recipes = set(os.path.basename(f)
-                      for f in self.cooker_data.pkg_fn.iterkeys())
-        recipes |= set(os.path.basename(f)
-                      for f in self.cooker.skiplist.iterkeys())
-        appended_recipes = self.cooker_data.appends.iterkeys()
-        appends_without_recipes = [self.cooker_data.appends[recipe]
-                                   for recipe in appended_recipes
-                                   if recipe not in recipes]
-        if appends_without_recipes:
-            appendlines = ('  %s' % append
-                           for appends in appends_without_recipes
-                           for append in appends)
-            logger.warn('No recipes available for:\n%s',
-                        '\n'.join(appendlines))
-            self.returncode |= 4
-
     def do_EOF(self, line):
         return True
 
diff --git a/bitbake/lib/bb/cooker.py b/bitbake/lib/bb/cooker.py
index ebf963d..5a70ba7 100644
--- a/bitbake/lib/bb/cooker.py
+++ b/bitbake/lib/bb/cooker.py
@@ -471,6 +471,21 @@ class BBCooker:
                 return pri
         return 0
 
+    def die_if_any_appends_with_no_recipes( self ):
+        recipes = set(os.path.basename(f)
+                      for f in self.status.pkg_fn.iterkeys())
+        recipes |= set(os.path.basename(f)
+                      for f in self.skiplist.iterkeys())
+        appended_recipes = self.appendlist.iterkeys()
+        appends_without_recipes = [self.appendlist[recipe]
+                                   for recipe in appended_recipes
+                                   if recipe not in recipes]
+        if appends_without_recipes:
+            appendlines = ('  %s' % append
+                           for appends in appends_without_recipes
+                           for append in appends)
+            bb.fatal('No recipes available for:\n%s' % '\n'.join(appendlines))
+
     def buildDepgraph( self ):
         all_depends = self.status.all_depends
         pn_provides = self.status.pn_provides
@@ -940,6 +955,7 @@ class BBCooker:
 
         if not self.parser.parse_next():
             collectlog.debug(1, "parsing complete")
+            self.die_if_any_appends_with_no_recipes()
             self.buildDepgraph()
             self.state = state.running
             return None
-- 
1.7.1

Re: [PATCH 1/1] die if a .bbappend file matches no existing .bb recipe

[Cui, Dexuan]

Martin Jansa wrote:
> On Mon, Jun 20, 2011 at 6:34 AM, Dexuan Cui <dexuan.cui@intel.com>
> wrote: 
>> This patch moves the logic of show_appends_with_no_recipes from
>> bitbake-layers into bitbake, and makes the script die with a fatal
>> error message printed. 
> 
> I agree that this is problem, but I'm not sure if it should be fatal.
> 
> Imagine the case when you enable some layer managed by someone else
> (lets call it LS) and you're using different oe-core revision, maybe
> current HEAD and that LS wasn't updated for that or vice versa you're
> using some oe-core release version and you want to reuse some recipes
> from LS in current version.
> 
> I think that big fat warning that some .bbappends does not match
> should be enough to decide if it's fatal for me (and I'll kill that
> build) or that's fine (when I'm not interested in those .bbappends
> from LS and I'm using only some other .bb files from LS).
> 
> If we make it fatal then I would be forced to remove unmatched
> .bbappends from LS before build which can be difficult to share
> (unless I create own LS branch and use it in my distro).
Thanks a lot for the explanation! 
So looks we may as well change the "bb.fatal" to "bb.error"(that is not fatal and wouldn't be ignored by bitbake-layers).
This is the new patch (on a new branch dcui/bb-v2):
http://git.pokylinux.org/cgit/cgit.cgi/poky-contrib/commit/?h=dcui/bb-v2&id=2a520959f71ec2cd80ed2088bfcf082631161a1a

Thanks,
-- Dexuan

Re: [PATCH 1/1] die if a .bbappend file matches no existing .bb recipe

[Chris Larson]

On Mon, Jun 20, 2011 at 12:29 AM, Cui, Dexuan <dexuan.cui@intel.com> wrote:
> Martin Jansa wrote:
>> On Mon, Jun 20, 2011 at 6:34 AM, Dexuan Cui <dexuan.cui@intel.com>
>> wrote:
>>> This patch moves the logic of show_appends_with_no_recipes from
>>> bitbake-layers into bitbake, and makes the script die with a fatal
>>> error message printed.
>>
>> I agree that this is problem, but I'm not sure if it should be fatal.
>>
>> Imagine the case when you enable some layer managed by someone else
>> (lets call it LS) and you're using different oe-core revision, maybe
>> current HEAD and that LS wasn't updated for that or vice versa you're
>> using some oe-core release version and you want to reuse some recipes
>> from LS in current version.
>>
>> I think that big fat warning that some .bbappends does not match
>> should be enough to decide if it's fatal for me (and I'll kill that
>> build) or that's fine (when I'm not interested in those .bbappends
>> from LS and I'm using only some other .bb files from LS).
>>
>> If we make it fatal then I would be forced to remove unmatched
>> .bbappends from LS before build which can be difficult to share
>> (unless I create own LS branch and use it in my distro).
> Thanks a lot for the explanation!
> So looks we may as well change the "bb.fatal" to "bb.error"(that is not fatal and wouldn't be ignored by bitbake-layers).
> This is the new patch (on a new branch dcui/bb-v2):
> http://git.pokylinux.org/cgit/cgit.cgi/poky-contrib/commit/?h=dcui/bb-v2&id=2a520959f71ec2cd80ed2088bfcf082631161a1a
>

Are you sure this shouldn't be a warning? Remember that any error
displayed results in a non-zero exit code from bitbake.
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics

Re: [PATCH 1/1] die if a .bbappend file matches no existing .bb recipe

[Denys Dmytriyenko]

On Fri, Jun 24, 2011 at 11:16:53AM -0700, Chris Larson wrote:
> On Mon, Jun 20, 2011 at 12:29 AM, Cui, Dexuan <dexuan.cui@intel.com> wrote:
> > Martin Jansa wrote:
> >> On Mon, Jun 20, 2011 at 6:34 AM, Dexuan Cui <dexuan.cui@intel.com>
> >> wrote:
> >>> This patch moves the logic of show_appends_with_no_recipes from
> >>> bitbake-layers into bitbake, and makes the script die with a fatal
> >>> error message printed.
> >>
> >> I agree that this is problem, but I'm not sure if it should be fatal.
> >>
> >> Imagine the case when you enable some layer managed by someone else
> >> (lets call it LS) and you're using different oe-core revision, maybe
> >> current HEAD and that LS wasn't updated for that or vice versa you're
> >> using some oe-core release version and you want to reuse some recipes
> >> from LS in current version.
> >>
> >> I think that big fat warning that some .bbappends does not match
> >> should be enough to decide if it's fatal for me (and I'll kill that
> >> build) or that's fine (when I'm not interested in those .bbappends
> >> from LS and I'm using only some other .bb files from LS).
> >>
> >> If we make it fatal then I would be forced to remove unmatched
> >> .bbappends from LS before build which can be difficult to share
> >> (unless I create own LS branch and use it in my distro).
> > Thanks a lot for the explanation!
> > So looks we may as well change the "bb.fatal" to "bb.error"(that is not 
> > fatal and wouldn't be ignored by bitbake-layers).
> > This is the new patch (on a new branch dcui/bb-v2):
> > http://git.pokylinux.org/cgit/cgit.cgi/poky-contrib/commit/?h=dcui/bb-v2&id=2a520959f71ec2cd80ed2088bfcf082631161a1a
> 
> Are you sure this shouldn't be a warning? Remember that any error
> displayed results in a non-zero exit code from bitbake.

So, speaking of which - what is the practical use for bb.error? It gives an 
error message, but doesn't stop the build. Although it returns a non-zero exit 
code, which for most autobuilders indicate a failed build anyway... What's the 
point?

-- 
Denys

Re: [PATCH 1/1] die if a .bbappend file matches no existing .bb recipe

[Paul Eggleton]

Martin Jansa wrote:
> Imagine the case when you enable some layer managed by someone else
> (lets call it LS) and you're using different oe-core revision, maybe
> current HEAD and that LS wasn't updated for that or vice versa you're
> using some oe-core release version and you want to reuse some recipes
> from LS in current version.
> 
> I think that big fat warning that some .bbappends does not match
> should be enough to decide if it's fatal for me (and I'll kill that
> build) or that's fine (when I'm not interested in those .bbappends
> from LS and I'm using only some other .bb files from LS).
> 
> If we make it fatal then I would be forced to remove unmatched
> .bbappends from LS before build which can be difficult to share
> (unless I create own LS branch and use it in my distro).

I see what you're saying, but I'm worried about the visiblity (or lack 
thereof) of these warnings.  If you start a build, go off somewhere and come 
back when the build is part way through or finished, you may be oblivious to 
the fact that there might be a serious problem - i.e. the customisations you 
expected to be applied haven't been.

It all depends on whether the bbappends are supposed to apply to recipes that 
are to be used in the build you're doing - if they are, then IMHO the error 
should be fatal. I wonder if it's practical to make it work that way...?

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: [PATCH 1/1] die if a .bbappend file matches no existing .bb recipe

[Richard Purdie]

On Fri, 2011-06-24 at 14:38 -0400, Denys Dmytriyenko wrote:
> On Fri, Jun 24, 2011 at 11:16:53AM -0700, Chris Larson wrote:
> > On Mon, Jun 20, 2011 at 12:29 AM, Cui, Dexuan <dexuan.cui@intel.com> wrote:
> > > Martin Jansa wrote:
> > >> On Mon, Jun 20, 2011 at 6:34 AM, Dexuan Cui <dexuan.cui@intel.com>
> > >> wrote:
> > >>> This patch moves the logic of show_appends_with_no_recipes from
> > >>> bitbake-layers into bitbake, and makes the script die with a fatal
> > >>> error message printed.
> > >>
> > >> I agree that this is problem, but I'm not sure if it should be fatal.
> > >>
> > >> Imagine the case when you enable some layer managed by someone else
> > >> (lets call it LS) and you're using different oe-core revision, maybe
> > >> current HEAD and that LS wasn't updated for that or vice versa you're
> > >> using some oe-core release version and you want to reuse some recipes
> > >> from LS in current version.
> > >>
> > >> I think that big fat warning that some .bbappends does not match
> > >> should be enough to decide if it's fatal for me (and I'll kill that
> > >> build) or that's fine (when I'm not interested in those .bbappends
> > >> from LS and I'm using only some other .bb files from LS).
> > >>
> > >> If we make it fatal then I would be forced to remove unmatched
> > >> .bbappends from LS before build which can be difficult to share
> > >> (unless I create own LS branch and use it in my distro).
> > > Thanks a lot for the explanation!
> > > So looks we may as well change the "bb.fatal" to "bb.error"(that is not 
> > > fatal and wouldn't be ignored by bitbake-layers).
> > > This is the new patch (on a new branch dcui/bb-v2):
> > > http://git.pokylinux.org/cgit/cgit.cgi/poky-contrib/commit/?h=dcui/bb-v2&id=2a520959f71ec2cd80ed2088bfcf082631161a1a
> > 
> > Are you sure this shouldn't be a warning? Remember that any error
> > displayed results in a non-zero exit code from bitbake.
> 
> So, speaking of which - what is the practical use for bb.error? It gives an 
> error message, but doesn't stop the build. Although it returns a non-zero exit 
> code, which for most autobuilders indicate a failed build anyway... What's the 
> point?

It denotes something which the user really needs to know about and fix.
The sanity tests are good example and I'd really like to see sanity
issues becoming bb.errors in most cases.

You can also think about it as being a point on the error severity
scale:

Note: Information only
Warning: Something happened which the user likely needs to fix
Error: Something happened the user is strongly recommended to fix - set 
       exit code accordingly.
Fatal: Something bad happened and there is no hope so stop.

I think in the scheme of different error priorities and actions, it
makes sense...

Cheers,

Richard

Re: [PATCH 1/1] die if a .bbappend file matches no existing .bb recipe

[Chris Larson]

On Mon, Jun 27, 2011 at 6:49 AM, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
> On Fri, 2011-06-24 at 14:38 -0400, Denys Dmytriyenko wrote:
>> On Fri, Jun 24, 2011 at 11:16:53AM -0700, Chris Larson wrote:
>> > On Mon, Jun 20, 2011 at 12:29 AM, Cui, Dexuan <dexuan.cui@intel.com> wrote:
>> > > Martin Jansa wrote:
>> > >> On Mon, Jun 20, 2011 at 6:34 AM, Dexuan Cui <dexuan.cui@intel.com>
>> > >> wrote:
>> > >>> This patch moves the logic of show_appends_with_no_recipes from
>> > >>> bitbake-layers into bitbake, and makes the script die with a fatal
>> > >>> error message printed.
>> > >>
>> > >> I agree that this is problem, but I'm not sure if it should be fatal.
>> > >>
>> > >> Imagine the case when you enable some layer managed by someone else
>> > >> (lets call it LS) and you're using different oe-core revision, maybe
>> > >> current HEAD and that LS wasn't updated for that or vice versa you're
>> > >> using some oe-core release version and you want to reuse some recipes
>> > >> from LS in current version.
>> > >>
>> > >> I think that big fat warning that some .bbappends does not match
>> > >> should be enough to decide if it's fatal for me (and I'll kill that
>> > >> build) or that's fine (when I'm not interested in those .bbappends
>> > >> from LS and I'm using only some other .bb files from LS).
>> > >>
>> > >> If we make it fatal then I would be forced to remove unmatched
>> > >> .bbappends from LS before build which can be difficult to share
>> > >> (unless I create own LS branch and use it in my distro).
>> > > Thanks a lot for the explanation!
>> > > So looks we may as well change the "bb.fatal" to "bb.error"(that is not
>> > > fatal and wouldn't be ignored by bitbake-layers).
>> > > This is the new patch (on a new branch dcui/bb-v2):
>> > > http://git.pokylinux.org/cgit/cgit.cgi/poky-contrib/commit/?h=dcui/bb-v2&id=2a520959f71ec2cd80ed2088bfcf082631161a1a
>> >
>> > Are you sure this shouldn't be a warning? Remember that any error
>> > displayed results in a non-zero exit code from bitbake.
>>
>> So, speaking of which - what is the practical use for bb.error? It gives an
>> error message, but doesn't stop the build. Although it returns a non-zero exit
>> code, which for most autobuilders indicate a failed build anyway... What's the
>> point?
>
> It denotes something which the user really needs to know about and fix.
> The sanity tests are good example and I'd really like to see sanity
> issues becoming bb.errors in most cases.
>
> You can also think about it as being a point on the error severity
> scale:
>
> Note: Information only
> Warning: Something happened which the user likely needs to fix
> Error: Something happened the user is strongly recommended to fix - set
>       exit code accordingly.
> Fatal: Something bad happened and there is no hope so stop.
>
> I think in the scheme of different error priorities and actions, it
> makes sense...

I really don't think they're very useful right now. If our UIs
actually captured the errors and summarized them at the end of the
build, as well as had them in a global log, then I could see them
being of use, but having an error message that might have scrolled
past an hour ago result in a non-zero exit code is far from ideal. As
a user, I have no idea why it seems to have failed.
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics

Re: [PATCH 1/1] die if a .bbappend file matches no existing .bb recipe

[Cui, Dexuan]

Chris Larson wrote:
> On Mon, Jun 27, 2011 at 6:49 AM, Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
>> On Fri, 2011-06-24 at 14:38 -0400, Denys Dmytriyenko wrote:
>>> On Fri, Jun 24, 2011 at 11:16:53AM -0700, Chris Larson wrote:
>>>> On Mon, Jun 20, 2011 at 12:29 AM, Cui, Dexuan
>>>> <dexuan.cui@intel.com> wrote: 
>>>>> Martin Jansa wrote:
>>>>>> On Mon, Jun 20, 2011 at 6:34 AM, Dexuan Cui
>>>>>> <dexuan.cui@intel.com> wrote:
>>>>>>> This patch moves the logic of show_appends_with_no_recipes from
>>>>>>> bitbake-layers into bitbake, and makes the script die with a
>>>>>>> fatal error message printed.
>>>>>> 
>>>>>> I agree that this is problem, but I'm not sure if it should be
>>>>>> fatal. 
>>>>>> 
>>>>>> Imagine the case when you enable some layer managed by someone
>>>>>> else (lets call it LS) and you're using different oe-core
>>>>>> revision, maybe current HEAD and that LS wasn't updated for that
>>>>>> or vice versa you're using some oe-core release version and you
>>>>>> want to reuse some recipes from LS in current version. 
>>>>>> 
>>>>>> I think that big fat warning that some .bbappends does not match
>>>>>> should be enough to decide if it's fatal for me (and I'll kill
>>>>>> that build) or that's fine (when I'm not interested in those
>>>>>> .bbappends from LS and I'm using only some other .bb files from
>>>>>> LS). 
>>>>>> 
>>>>>> If we make it fatal then I would be forced to remove unmatched
>>>>>> .bbappends from LS before build which can be difficult to share
>>>>>> (unless I create own LS branch and use it in my distro).
>>>>> Thanks a lot for the explanation!
>>>>> So looks we may as well change the "bb.fatal" to "bb.error"(that
>>>>> is not fatal and wouldn't be ignored by bitbake-layers).
>>>>> This is the new patch (on a new branch dcui/bb-v2):
>>>>> http://git.pokylinux.org/cgit/cgit.cgi/poky-contrib/commit/?h=dcui/bb-v2&id=2a520959f71ec2cd80ed2088bfcf082631161a1a
>>>> 
>>>> Are you sure this shouldn't be a warning? Remember that any error
>>>> displayed results in a non-zero exit code from bitbake.
>>> 
>>> So, speaking of which - what is the practical use for bb.error? It
>>> gives an error message, but doesn't stop the build. Although it
>>> returns a non-zero exit code, which for most autobuilders indicate
>>> a failed build anyway... What's the point?
>> 
>> It denotes something which the user really needs to know about and
>> fix. The sanity tests are good example and I'd really like to see
>> sanity issues becoming bb.errors in most cases.
>> 
>> You can also think about it as being a point on the error severity
>> scale: 
>> 
>> Note: Information only
>> Warning: Something happened which the user likely needs to fix
>> Error: Something happened the user is strongly recommended to fix -
>> set       exit code accordingly. Fatal: Something bad happened and
>> there is no hope so stop. 
>> 
>> I think in the scheme of different error priorities and actions, it
>> makes sense...
> 
> I really don't think they're very useful right now. If our UIs
> actually captured the errors and summarized them at the end of the
> build, as well as had them in a global log, then I could see them
> being of use, but having an error message that might have scrolled
> past an hour ago result in a non-zero exit code is far from ideal. As
> a user, I have no idea why it seems to have failed.

I noticed in poky bb.error() doesn't cause bitbake to return a non-zero exit code.

Thanks,
-- Dexuan

Re: [PATCH 1/1] die if a .bbappend file matches no existing .bb recipe

[Richard Purdie]

On Mon, 2011-06-27 at 07:05 -0700, Chris Larson wrote:
> On Mon, Jun 27, 2011 at 6:49 AM, Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
> > On Fri, 2011-06-24 at 14:38 -0400, Denys Dmytriyenko wrote:
> >> On Fri, Jun 24, 2011 at 11:16:53AM -0700, Chris Larson wrote:
> >> > On Mon, Jun 20, 2011 at 12:29 AM, Cui, Dexuan <dexuan.cui@intel.com> wrote:
> >> > > Martin Jansa wrote:
> >> > >> On Mon, Jun 20, 2011 at 6:34 AM, Dexuan Cui <dexuan.cui@intel.com>
> >> > >> wrote:
> >> > >>> This patch moves the logic of show_appends_with_no_recipes from
> >> > >>> bitbake-layers into bitbake, and makes the script die with a fatal
> >> > >>> error message printed.
> >> > >>
> >> > >> I agree that this is problem, but I'm not sure if it should be fatal.
> >> > >>
> >> > >> Imagine the case when you enable some layer managed by someone else
> >> > >> (lets call it LS) and you're using different oe-core revision, maybe
> >> > >> current HEAD and that LS wasn't updated for that or vice versa you're
> >> > >> using some oe-core release version and you want to reuse some recipes
> >> > >> from LS in current version.
> >> > >>
> >> > >> I think that big fat warning that some .bbappends does not match
> >> > >> should be enough to decide if it's fatal for me (and I'll kill that
> >> > >> build) or that's fine (when I'm not interested in those .bbappends
> >> > >> from LS and I'm using only some other .bb files from LS).
> >> > >>
> >> > >> If we make it fatal then I would be forced to remove unmatched
> >> > >> .bbappends from LS before build which can be difficult to share
> >> > >> (unless I create own LS branch and use it in my distro).
> >> > > Thanks a lot for the explanation!
> >> > > So looks we may as well change the "bb.fatal" to "bb.error"(that is not
> >> > > fatal and wouldn't be ignored by bitbake-layers).
> >> > > This is the new patch (on a new branch dcui/bb-v2):
> >> > > http://git.pokylinux.org/cgit/cgit.cgi/poky-contrib/commit/?h=dcui/bb-v2&id=2a520959f71ec2cd80ed2088bfcf082631161a1a
> >> >
> >> > Are you sure this shouldn't be a warning? Remember that any error
> >> > displayed results in a non-zero exit code from bitbake.
> >>
> >> So, speaking of which - what is the practical use for bb.error? It gives an
> >> error message, but doesn't stop the build. Although it returns a non-zero exit
> >> code, which for most autobuilders indicate a failed build anyway... What's the
> >> point?
> >
> > It denotes something which the user really needs to know about and fix.
> > The sanity tests are good example and I'd really like to see sanity
> > issues becoming bb.errors in most cases.
> >
> > You can also think about it as being a point on the error severity
> > scale:
> >
> > Note: Information only
> > Warning: Something happened which the user likely needs to fix
> > Error: Something happened the user is strongly recommended to fix - set
> >       exit code accordingly.
> > Fatal: Something bad happened and there is no hope so stop.
> >
> > I think in the scheme of different error priorities and actions, it
> > makes sense...
> 
> I really don't think they're very useful right now. If our UIs
> actually captured the errors and summarized them at the end of the
> build, as well as had them in a global log, then I could see them
> being of use, but having an error message that might have scrolled
> past an hour ago result in a non-zero exit code is far from ideal. As
> a user, I have no idea why it seems to have failed.

Well, patches to improve the UIs in the regard are welcome. At least at
this point we can do this kind of thing at the UI level which is way
better than the situation used to be.

I'd also argue its better to have any indication there was a problem
than none at all...

Cheers,

Richard

Re: [PATCH 1/1] die if a .bbappend file matches no existing .bb recipe

[Richard Purdie]

On Mon, 2011-06-27 at 14:06 +0100, Paul Eggleton wrote:
> Martin Jansa wrote:
> > Imagine the case when you enable some layer managed by someone else
> > (lets call it LS) and you're using different oe-core revision, maybe
> > current HEAD and that LS wasn't updated for that or vice versa you're
> > using some oe-core release version and you want to reuse some recipes
> > from LS in current version.
> > 
> > I think that big fat warning that some .bbappends does not match
> > should be enough to decide if it's fatal for me (and I'll kill that
> > build) or that's fine (when I'm not interested in those .bbappends
> > from LS and I'm using only some other .bb files from LS).
> > 
> > If we make it fatal then I would be forced to remove unmatched
> > .bbappends from LS before build which can be difficult to share
> > (unless I create own LS branch and use it in my distro).
> 
> I see what you're saying, but I'm worried about the visiblity (or lack 
> thereof) of these warnings.  If you start a build, go off somewhere and come 
> back when the build is part way through or finished, you may be oblivious to 
> the fact that there might be a serious problem - i.e. the customisations you 
> expected to be applied haven't been.
> 
> It all depends on whether the bbappends are supposed to apply to recipes that 
> are to be used in the build you're doing - if they are, then IMHO the error 
> should be fatal. I wonder if it's practical to make it work that way...?

I think it should be fatal by default but have some kind of variable we
can set to disable it...

Cheers,

Richard

Re: [PATCH 1/1] die if a .bbappend file matches no existing .bb recipe

[Cui, Dexuan]

Richard Purdie wrote:
> On Mon, 2011-06-27 at 14:06 +0100, Paul Eggleton wrote:
>> Martin Jansa wrote:
>>> Imagine the case when you enable some layer managed by someone else
>>> (lets call it LS) and you're using different oe-core revision, maybe
>>> current HEAD and that LS wasn't updated for that or vice versa
>>> you're using some oe-core release version and you want to reuse
>>> some recipes from LS in current version. 
>>> 
>>> I think that big fat warning that some .bbappends does not match
>>> should be enough to decide if it's fatal for me (and I'll kill that
>>> build) or that's fine (when I'm not interested in those .bbappends
>>> from LS and I'm using only some other .bb files from LS).
>>> 
>>> If we make it fatal then I would be forced to remove unmatched
>>> .bbappends from LS before build which can be difficult to share
>>> (unless I create own LS branch and use it in my distro).
>> 
>> I see what you're saying, but I'm worried about the visiblity (or
>> lack thereof) of these warnings.  If you start a build, go off
>> somewhere and come back when the build is part way through or
>> finished, you may be oblivious to the fact that there might be a
>> serious problem - i.e. the customisations you expected to be applied
>> haven't been. 
>> 
>> It all depends on whether the bbappends are supposed to apply to
>> recipes that are to be used in the build you're doing - if they are,
>> then IMHO the error should be fatal. I wonder if it's practical to
>> make it work that way...? 
> 
> I think it should be fatal by default but have some kind of variable
> we can set to disable it...

Sorry -- what's the conclusion?
Keeping the v2 patch(http://git.pokylinux.org/cgit/cgit.cgi/poky-contrib/commit/?h=dcui/bb-v2&id=2a520959f71ec2cd80ed2088bfcf082631161a1a), or changing bb.error() to bb.warn()?

Thanks,
-- Dexuan

Re: [PATCH 1/1] die if a .bbappend file matches no existing .bb recipe

[Richard Purdie]

On Thu, 2011-06-30 at 00:03 +0800, Cui, Dexuan wrote:
> Sorry -- what's the conclusion?
> Keeping the v2 patch
> (http://git.pokylinux.org/cgit/cgit.cgi/poky-contrib/commit/?h=dcui/bb-v2&id=2a520959f71ec2cd80ed2088bfcf082631161a1a)
> , or changing bb.error() to bb.warn()?

Where you have:

  bb.error('No recipes available for:\n%s' % '\n'.join(appendlines))

this would become something like:

  msg = 'No recipes available for:\n%s' % '\n'.join(appendlines)
  if d.getVar("BB_DANGLINGAPPENDS_WARNONLY", False):
     bb.warn(msg)
  else:
     bb.fatal(msg)

which means we can have a strong default but advanced
users/distros/whoever can avoid this.

Cheers,

Richard

Re: [PATCH 1/1] die if a .bbappend file matches no existing .bb recipe

[Cui, Dexuan]

Richard Purdie wrote:
> On Thu, 2011-06-30 at 00:03 +0800, Cui, Dexuan wrote:
>> Sorry -- what's the conclusion?
>> Keeping the v2 patch
>> (http://git.pokylinux.org/cgit/cgit.cgi/poky-contrib/commit/?h=dcui/bb-v2&id=2a520959f71ec2cd80ed2088bfcf082631161a1a)
>> , or changing bb.error() to bb.warn()?
> 
> Where you have:
> 
>   bb.error('No recipes available for:\n%s' % '\n'.join(appendlines))
> 
> this would become something like:
> 
>   msg = 'No recipes available for:\n%s' % '\n'.join(appendlines)
>   if d.getVar("BB_DANGLINGAPPENDS_WARNONLY", False):
>      bb.warn(msg)
>   else:
>      bb.fatal(msg)
> 
> which means we can have a strong default but advanced
> users/distros/whoever can avoid this.
Hi Richard, thanks very much for the explanation!

I'll make and test a new version like this.

Thanks,
-- Dexuan

Re: [PATCH 1/1] die if a .bbappend file matches no existing .bb recipe

[Denys Dmytriyenko]

On Wed, Jun 29, 2011 at 05:14:57PM +0100, Richard Purdie wrote:
> On Thu, 2011-06-30 at 00:03 +0800, Cui, Dexuan wrote:
> > Sorry -- what's the conclusion?
> > Keeping the v2 patch
> > (http://git.pokylinux.org/cgit/cgit.cgi/poky-contrib/commit/?h=dcui/bb-v2&id=2a520959f71ec2cd80ed2088bfcf082631161a1a)
> > , or changing bb.error() to bb.warn()?
> 
> Where you have:
> 
>   bb.error('No recipes available for:\n%s' % '\n'.join(appendlines))
> 
> this would become something like:
> 
>   msg = 'No recipes available for:\n%s' % '\n'.join(appendlines)
>   if d.getVar("BB_DANGLINGAPPENDS_WARNONLY", False):
>      bb.warn(msg)
>   else:
>      bb.fatal(msg)
> 
> which means we can have a strong default but advanced
> users/distros/whoever can avoid this.

Thanks! That's a nice compromise.

-- 
Denys

Re: [PATCH 1/1] die if a .bbappend file matches no existing .bb recipe

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 1020 bytes --]

On Wed, Jun 29, 2011 at 12:51:39PM -0400, Denys Dmytriyenko wrote:
> On Wed, Jun 29, 2011 at 05:14:57PM +0100, Richard Purdie wrote:
> > On Thu, 2011-06-30 at 00:03 +0800, Cui, Dexuan wrote:
> > > Sorry -- what's the conclusion?
> > > Keeping the v2 patch
> > > (http://git.pokylinux.org/cgit/cgit.cgi/poky-contrib/commit/?h=dcui/bb-v2&id=2a520959f71ec2cd80ed2088bfcf082631161a1a)
> > > , or changing bb.error() to bb.warn()?
> > 
> > Where you have:
> > 
> >   bb.error('No recipes available for:\n%s' % '\n'.join(appendlines))
> > 
> > this would become something like:
> > 
> >   msg = 'No recipes available for:\n%s' % '\n'.join(appendlines)
> >   if d.getVar("BB_DANGLINGAPPENDS_WARNONLY", False):
> >      bb.warn(msg)
> >   else:
> >      bb.fatal(msg)
> > 
> > which means we can have a strong default but advanced
> > users/distros/whoever can avoid this.
> 
> Thanks! That's a nice compromise.

Agreed, looks good to me.

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]