[OE-core] [oe-core][PATCH 0/1] blacklist: add BPNBLACKLIST support

[Paul Eggleton]

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" <jslater at windriver.com
> > 
> > <mailto:jslater at 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