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
prev parent 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