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. 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