diff options
author | Ulf Magnusson <ulfalizer@gmail.com> | 2016-10-01 04:46:52 +0200 |
---|---|---|
committer | Richard Purdie <richard.purdie@linuxfoundation.org> | 2016-10-03 15:46:21 +0100 |
commit | 5a074e8a26d27ea9c4f31e2b75b2b14f6e0641d3 (patch) | |
tree | 036fdad4c9ebf903cb704d69c3f2f03a6532959f /meta/classes/toolchain-scripts-base.bbclass | |
parent | 01e3ac73860a24710852383a15bb5d01db13de57 (diff) | |
download | openembedded-core-5a074e8a26d27ea9c4f31e2b75b2b14f6e0641d3.tar.gz openembedded-core-5a074e8a26d27ea9c4f31e2b75b2b14f6e0641d3.tar.bz2 openembedded-core-5a074e8a26d27ea9c4f31e2b75b2b14f6e0641d3.zip |
package_deb.bbclass: Use bb.fatal() instead of raising FuncFailed
This sets a good example and avoids unnecessarily contributing to
perceived complexity and cargo culting.
Motivating quote below:
< kergoth> the *original* intent was for the function/task to error via
whatever appropriate means, bb.fatal, whatever, and
funcfailed was what you'd catch if you were calling
exec_func/exec_task. that is, it's what those functions
raise, not what metadata functions should be raising
< kergoth> it didn't end up being used that way
< kergoth> but there's really never a reason to raise it yourself
FuncFailed.__init__ takes a 'name' argument rather than a 'msg'
argument, which also shows that the original purpose got lost.
Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Diffstat (limited to 'meta/classes/toolchain-scripts-base.bbclass')
0 files changed, 0 insertions, 0 deletions