How to override bitbake.conf defaults in layers properly?

How to override bitbake.conf defaults in layers properly?

[Koen Kooi]

Hi,

I spent the morning backporting kernel.bbclass changes to the meta-oe denzil branch and I've run into a problem: STAGING_KERNEL_DIR needs to change to match the updated class. In this specific case I can work with Scott and Eric to see if those kernel.bbclass changes can go into oe-core and meta-oe at the same time. That's something for next week :) In the meantime I'm wondering what the best way is to fix this in cases where you can't influence oe-core.

I see a number of options:

1) set STAGING_KERNEL_DIR in layer.conf. I don't know if that's parsed before or after bitbake.conf, but it feels like the cleanest solution
2) set it in $DISTRO.conf. Easy enough, breaks every other distro out there
3) copy over bitbake.conf. Might work with some BBPATH magic, but in the end doesn't scale when >1 layers do it
4) provide a custom denzil branch of oe-core, another easy way, but very antisocial

I'm not into the layering details enough to see what the effects of 1) would be, could the knowledgable people chime in please?

regards,

Koen

Re: How to override bitbake.conf defaults in layers properly?

[Paul Eggleton]

On Thursday 16 August 2012 13:57:44 Koen Kooi wrote:
> I spent the morning backporting kernel.bbclass changes to the meta-oe denzil
> branch and I've run into a problem: STAGING_KERNEL_DIR needs to change to
> match the updated class. In this specific case I can work with Scott and
> Eric to see if those kernel.bbclass changes can go into oe-core and meta-oe
> at the same time. That's something for next week :) In the meantime I'm
> wondering what the best way is to fix this in cases where you can't
> influence oe-core.

So let's be clear, having a copy of kernel.bbclass in meta-oe is half the 
reason you have this problem. The sooner we get out of this situation the 
better, IMHO.

> I see a number of options:
> 
> 1) set STAGING_KERNEL_DIR in layer.conf. I don't know if that's parsed
> before or after bitbake.conf, but it feels like the cleanest solution 

layer.conf for each layer is parsed very early - before bitbake.conf, so if 
you're looking to alter things that are set in bitbake.conf there it's not 
really going to work unless you use override hacks.

> 2) set it in $DISTRO.conf. Easy enough, breaks every other distro out there

To answer for everyone else's benefit, this is normally the correct place to 
globally override defaults set in bitbake.conf, and for the avoidance of 
confusion, settings in the distro config will absolutely take precedence. It's 
not workable in this situation, but this situation is a special one.

> 3) copy over bitbake.conf. Might work with some BBPATH magic, but in the end
> doesn't scale when >1 layers do it

With all of the other settings in bitbake.conf and the maintenance pain this 
would lead to this is not a good idea.

> 4) provide a custom denzil branch of oe-core, another easy way, but very
> antisocial

Perhaps, but if the changes were not accepted in OE-Core denzil branch it 
would be more than a little antisocial to expect to impose them via meta-oe.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre