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? Is BBMASK_forcevariable the right workaround for this? Or is there some layer priority scheme beyond the ordering in the bblayers.conf file that I should playing nice with? Thanks for your help, really! - Chris On Wed, Mar 1, 2017 at 5:03 PM, Paul Eggleton <paul.eggle...@linux.intel.com> wrote: > Hi Chris, > > On Thursday, 2 March 2017 11:31:42 AM NZDT chris warth wrote: >> Thanks, all. I wanted to share the solution. >> >> 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. > > Cheers, > Paul > > > -- > > Paul Eggleton > Intel Open Source Technology Centre -- _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
