On Tue, 2017-02-28 at 14:33 -0600, Aníbal Limón wrote: > > On 02/28/2017 02:09 PM, Patrick Ohly wrote: > > 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? > > The requirement is DISTRO and BSP layers aren't allowed to automatically > change the MACHINE or DISTRO variable that causes the signatures to change.
I do not fully understand this explanation. Can you give an example for the kind of misbehavior what the test is meant to catch? > > 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. > > It is expected to change recipe signatures when the machine change, this > leaves me other question. what signatures are expected to change when > set a different MACHINE? Everything that is machine-specific may change, for example image recipes and kernel (although even that is a slight simplification, as meta-intel intentionally shares kernels between different MACHINE configs). The real-world test is: can two BSP layers be combined in a single distro so that one can build first for one MACHINE, then the other (or, when using multiconfig, even in a single build)? If any shared package changes as result of changing the MACHINE, then that won't work. -- 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