Openembedded Core Discussions
 help / color / mirror / Atom feed
From: Paul Eggleton <paul.eggleton@linux.intel.com>
To: Koen Kooi <koen@dominion.thruhere.net>
Cc: openembedded-core@lists.openembedded.org
Subject: Re: How to override bitbake.conf defaults in layers properly?
Date: Thu, 16 Aug 2012 14:15:09 +0100	[thread overview]
Message-ID: <4232599.R290qD4K8p@helios> (raw)
In-Reply-To: <A2678AC1-3CB1-4405-BB18-8441249ED0EE@dominion.thruhere.net>

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



      reply	other threads:[~2012-08-16 13:27 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-08-16 11:57 How to override bitbake.conf defaults in layers properly? Koen Kooi
2012-08-16 13:15 ` Paul Eggleton [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4232599.R290qD4K8p@helios \
    --to=paul.eggleton@linux.intel.com \
    --cc=koen@dominion.thruhere.net \
    --cc=openembedded-core@lists.openembedded.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox