On Mon, 2017-02-20 at 15:12 -0600, Aníbal Limón wrote: > common.test_signatures: Test executed in BSP and DISTRO layers to review > doesn't comes with recipes that changes the signatures.
I have a question about the goal for this test: is it meant to detect layers which incorrectly change the signatures of allarch recipes or recipes which share the same tune flags with other machines? Let's take MACHINE=edison as an example. Modifying allarch creates a conflict with basically all other machines in a distro. Example for something not allowed: VOLATILE_BINDS_append_pn-volatile-binds_edison = " /var/volatile/foo /var/foo \n" This can be detected by comparing against OE-core, but only when testing with MACHINE=edison. More difficult to detect is modifying recipes with the same tune flags, which is the majority of the recipes. MACHINE=edison and MACHINE=intel-core2-32 both compile for the same target architecture, so something like this is incorrect: do_install_append_pn-base-files_edison () { echo "Built for Edison" >>${D}${sysconfdir}/motd } This can only be detected when testing with both MACHINE=edison and MACHINE=intel-core2-32 - at least I think MACHINE=qemux86 uses different tune flags (haven't checked). My point is, the test probably needs to be extended to run with a set of machines, and that set of machines must be broad enough to cover a variety of common tune flags. The corresponding selftest, test_sstate_sametune_samesigs in sstatetests.py, has the same limitation of its scope, i.e. doesn't actually test with real machine definitions. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core