[yocto] BBMASK not working for me?

[Paul Eggleton]

On Thursday, 2 March 2017 2:14:13 PM NZDT chris warth wrote:
> <paul.eggleton at linux.intel.com> wrote:
> > On Thursday, 2 March 2017 11:31:42 AM NZDT chris warth wrote:
> >> This vendor-supplied version of yocto looks like 2.0, so the space
> >> separated expressions are not available.
> >> After putting some print statements in cooker.py I discovered that
> >> appending to BBMASK in conf/bblayers.conf or conf/local.conf has no
> >> effect.  It was not until I modified BBMASK_forcevariable in my
> >> conf/bblayers.conf  that I saw any change in behavior.
> >> 
> >> BBMASK_forcevariable = ".*openjre|.*openjdk|.*qemu_qoriq"
> >> 
> >> This inability to modify BBMASK unless using _forcevariable was also
> >> noted last year.
> >> https://lists.yoctoproject.org/pipermail/yocto/2016-September/032033.html
> > 
> > That sounds strange. Did you use bitbake -e | less to see where your non-
> > forcevariable setting was being overridden? More than likely you have a
> > layer or some other configuration you're bringing in and that's simply
> > setting it with = at some point later in parsing than local.conf. The
> > history of the BBMASK variable shown through bitbake -e will tell you
> > exactly where that is.
>
> Thank you, Paul.  I didn't know about bitbake -e.
> As you predicted, it shows that an earlier layer is setting BBMASK
> with equals, in this case the
> meta-freescale layer.
> 
> BBMASK=".*openjre|.*openjdk"
> 
> Should I be mad at the vendor for being careless?

Personally I think you should, yes. BSP layers really should not be setting 
BBMASK, IMO. Interestingly though I can't see this BBMASK in meta-fsl-arm / 
meta-fsl-ppc either in current master or in the history for master - where is 
this exactly?

> Is BBMASK_forcevariable the right workaround for this?

You should be able to use _append, provided you are OK with openjre/openjdk 
recipes also being masked out.

> Or is there some layer priority scheme beyond the ordering in the
> bblayers.conf file that I should playing nice with?

I usually describe BBMASK as a huge hammer - it prevents bitbake from even 
reading recipes / bbappends that match it. My recommendation is not to use it 
at all unless there's no other way.

One alternative way of dealing with recipes you don't want to have built is to 
use PNBLACKLIST. You do have to know the exact recipe name (PN) that you want 
to blacklist, you can't do it by regex - but usually that's not too much of a 
problem. The advantage of PNBLACKLIST is that you get to specify a reason why 
the recipe is blacklisted, and thus it is usually much more obvious what's 
going on when the recipe is requested anywhere (be it directly on the bitbake 
command line or indirectly as a dependency) - the reason will be printed in 
the resulting error. The actual filename in this case is qemu-qoriq_git.bb 
meaning that the PN is unique, so you can do this for example:

PNBLACKLIST[qemu-qoriq] = "Not supported by XYZ corp"

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre