> -----Original Message----- > From: Paul Eggleton [mailto:paul.eggle...@linux.intel.com] > Sent: Wednesday, June 22, 2016 7:30 PM > To: openembedded-core@lists.openembedded.org > Cc: Hatle, Mark; Slater, Joseph; Khem Raj > Subject: Re: [OE-core] [oe-core][PATCH 0/1] blacklist: add BPNBLACKLIST > support > > On Wed, 22 Jun 2016 17:45:55 Mark Hatle wrote: > > On 6/22/16 5:35 PM, Khem Raj wrote: > > > On Jun 22, 2016 2:59 PM, "Joe Slater" <jsla...@windriver.com > > > > > > <mailto:jsla...@windriver.com>> wrote: > > >> We have encountered some issues with the use of PNBLACKLIST in recipes. > > >> In particular, PNBLACKLIST[pkg] will not suppress building of lib32-pkg > > >> or lib64-pkg so world builds can fail unexpectedly. > > >> > > >> One solution could be to implement BPNBLACKLIST[] which checks BPN > > >> instead > > >> of PN when a recipe is being parsed. I have included a patch to do this. > > >> > > >> If this were adopted, there are many recipes under meta-openembedded that > > >> should probably changed to use BPNBLACKLIST instead of PNBLACKLIST. > > > > > > Bpn will also mean native and nativesdk among others. I think its better > > > to list multilibs explicitly. > > > > This is intentional. > > > > The problem with saying we have to list multilibs explicitly. multilib > > naming is arbitrary. I can say that it probably fits the pattern of lib64, > > lib32, libn32 and libx32.... but it doesn't have to. > > > > But then I'd also need to blacklist native and nativesdk versions as well.. > > so for a simple recipe that for some reason I want blacklisted, it's easier > > to hack the recipe to just blacklist itself -- then enter 7 or more > > blacklists. > > > > Using the BPNBLACKLIST I can blacklist a single recipe with one command and > > not worry about multilibs, class extensions, etc. > > > > (The patch leave PNBLACKLIST, specifically so that in the case where you > > want only partial usage blacklisted you can.) > > So blacklist.bbclass already has code to extend PNBLACKLIST with multilib > variants - so we don't actually need this for multilib, right? It only helps > cover multilib and native/nativesdk AFAICT.
But the original problem was that PNBLACKLIST[] does not create more varflags for multilib when used in a recipe. Anyway, I like your approach. Of course, I also liked introducing a variable named SELFBLACKLIST, too. I guess, then, PNBLACKLIST_class-target in a recipe would be the same as PNBLACKLIST[pkg] in a conf file is today (if pkg is a "vanilla" name). Maybe the old syntax could be deprecated and the eventhandler in the class ditched at some point? Joe > > If we are going to make changes here I do have an alternative suggestion - > a while ago I wrote this patch but never got around to sending it because > I wasn't quite sure if it's the right approach. It makes PNBLACKLIST work > a bit more like other variables where you use overrides rather than > varflags to make it specific to a recipe: > > http://git.yoctoproject.org/cgit/cgit.cgi/poky- > contrib/commit/?h=paule/stuff3&id=7383419cbe69c4d62b9695e6ae65adc8b54741f7 > > Does anyone else see value in this? > > Cheers, > Paul > > -- > > Paul Eggleton > Intel Open Source Technology Centre -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
