Re: [PATCH] event: Fix event handlers to raise SkipPackage

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Fri, 2014-05-30 at 13:32 +0100, Richard Purdie wrote:
> If an event handler triggers a SkipPackage event, we really want that
> event to be received and processed by the higher code levels. Currently
> it was getting caught and ignored which was leading to recipes
> being present when they clearly shouldn't have been.
> 
> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
> 
> diff --git a/bitbake/lib/bb/event.py b/bitbake/lib/bb/event.py
> index e205043..a95db52 100644
> --- a/bitbake/lib/bb/event.py
> +++ b/bitbake/lib/bb/event.py
> @@ -96,6 +96,8 @@ def fire_class_handlers(event, d):
>          if name in _catchall_handlers or name in evt_hmap:
>              try:
>                  execute_handler(name, handler, event, d)
> +            except bb.parse.SkipPackage:
> +                raise
>              except Exception:
>                  continue
>  

I'm just looking at another bug and this try/except Exception doesn't
make sense to me. It basically comes from:

http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/bitbake/lib/bb/event.py?h=rpurdie/t222&id=37cb4cc02b2e2b6c338c5943747e0a1ef15176b3

although the BaseException was changed to an Exception so that
SystemExit would pass through.

The problem is that if a handler like ConfigParsed raises an error
staying "eek stop", the system will merrily swallow it and the build
will continue. Ditto something like an ExpansionError.

Specifically, I really want to do:

http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=rpurdie/t222&id=6fe4e8aee3ac5b3ea9f285eae373c36de46c094e

since actually raising a SystemExit is pretty evil. Most of the build
works fine with this, except for the event handlers and its due to the
above clause. I've long wondered where the problem was but never dug
into it as yet, it now turns out its this.

So is there a good reason to keep that "continue" there or can we remove
this and assume is the handler is raising an exception, its an error?

Chris, any thoughts on what this was aiming to do originally?

Cheers,

Richard