On Thu, 2016-01-14 at 18:15 -0800, Robert Yang wrote:
> * If more than one files have the same QA issue, package_qa_walk()
> can
> only print the last one, others are overrided, for example:
> messages["host-user-contaminated"] = "foo1"
> messages["host-user-contaminated"] = "foo2"
> Only foo2 will be printed, this patch fixes the issue.
>
> * Remove unused parameter "path" from package_qa_walk()
> The path is a useless parameter in package_qa_walk() since it has
> been
> redined inside.
>
> [YOCTO #8436]
>
> Signed-off-by: Robert Yang <[email protected]>
> ---
> meta/classes/insane.bbclass | 20 +++++++++++++++++---
> 1 file changed, 17 insertions(+), 3 deletions(-)
Whilst your proposal is self contained, it doesn't really do anything
to help the readability of this code which is pretty horrific already,
if anything it just makes the code even more convoluted. I'd propose
something more radical, like:
diff --git a/meta/classes/insane.bbclass b/meta/classes/insane.bbclass
index acf8639..03028f8 100644
--- a/meta/classes/insane.bbclass
+++ b/meta/classes/insane.bbclass
@@ -189,6 +189,12 @@ def package_qa_handle_error(error_class, error_msg, d):
bb.note("QA Issue: %s [%s]" % (error_msg, error_class))
return True
+def package_qa_add_message(messages, section, message):
+ if section not in messages:
+ messages[section] = message
+ else:
+ messages[section] = messages[section] + "\n" + message
+
QAPATHTEST[libexec] = "package_qa_check_libexec"
def package_qa_check_libexec(path,name, d, elf, messages):
@@ -198,7 +204,7 @@ def package_qa_check_libexec(path,name, d, elf, messages):
return True
if 'libexec' in path.split(os.path.sep):
- messages["libexec"] = "%s: %s is using libexec please relocate to %s"
% (name, package_qa_clean_path(path, d), libexec)
+ package_qa_add_message(messages, "libexec", "%s: %s is using libexec
please relocate to %s" % (name, package_qa_clean_path(path, d), libexec))
return False
return True
This will obviously be a bit more work to make the patch but will IMO
result in a cleaner piece of code as an end result.
Cheers,
Richard
--
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core
