> -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of > Frans Meulenbroeks > Sent: Thursday, September 09, 2010 5:12 AM > To: [email protected]; [email protected] > Subject: Re: [oe] [PATCH] base.bbclass: fix soc-family test > > 2010/9/9 Phil Blundell <[email protected]>: > > On Thu, 2010-09-09 at 09:11 +0200, Frans Meulenbroeks wrote: > >> 2010/9/2 Frans Meulenbroeks <[email protected]>: > >> > - if this_soc_family and not re.match(need_machine, > this_soc_family): > >> > + if (this_soc_family and not re.match(need_machine, > this_soc_family)) or not this_soc_family: > >> > raise bb.parse.SkipPackage("incompatible with > machine %s" % this_machine) > > > > I am still far from convinced that this hunk of SOC_FAMILY code is > > desirable to have in the first place but, if it's going to stay there, > > clearly it should be fixed so that it doesn't cause problems for > > non-users. > > > > So, yes, your patch looks fine to me. > > > > p. > > > Phil, thanks for the feedback. > > I'm not too sure on the usefulness of it either, but there is some > breakage so we should either revert the patch or fix it. > > Actually the SOC_FAMILY got pushed before the review was concluded. > Technically it got the ack's but the discussion was still ongoing when > this was pushed. > What also makes it fishy is that all acks are from the same company > (which is the same one as the person who submitted the patch): > > Signed-off-by: Chase Maupin <[email protected]> > Acked-by: Denys Dmytriyenko <[email protected]> > Acked-by: Koen Kooi <[email protected]> > Signed-off-by: Koen Kooi <[email protected]> > > I would suggest modifying the commit policy disallowing these kind of > things, saying the two Ack's must be from two developers not > affiliated with the same company. > (actually we might even want to take it further and saying that global > changes that affect everyone would require ACK's from developers from > more than one distro). > > Question to the TSC: should the SOC_FAMILY patch be reverted and put > on hold until there is agreement whether or not we want this?
Frans, As the person who submitted this change I'd like to ask that it not be reverted. I am using it currently so that when defining COMPATIBLE_MACHINE for recipes targeted at OMAP3 devices I do not have to keep a rolling list of all the various OMAP3 devices. This can quickly become: COMPATIBLE_MACHINE = "dm37x-evm|am37x-evm|omap3evm|am3517-evm|beagleboard|......" Instead by allowing SOC_FAMILY to be used as a COMPATIBLE_MACHINE this can be handled cleanly with: COMPATIBLE_MACHINE = "omap3" Please consider this use case. I would much prefer if your fix was put into the base.bbclass than if this were removed. > > Frans > > _______________________________________________ > Openembedded-devel mailing list > [email protected] > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel _______________________________________________ Openembedded-devel mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
