[oe] RFC: Improve our default conf file setup

Chris Larson clarson at kergoth.com
Sat Feb 20 01:39:27 UTC 2010


On Thu, Feb 18, 2010 at 9:58 AM, Richard Purdie <rpurdie at rpsys.net> wrote:

> On Thu, 2010-02-18 at 09:13 -0700, Chris Larson wrote:
> > With COLLECTIONS (and BBLAYERS could work similarly), all the overlay
> > priorities and bbpath ordering are automatically determined based on the
> > order of entries in the variable.  Documented as highest-to-lowest.
> >
> > Note that I'm not necessarily arguing against the use of a per-layer
> > configuration file, as this seems like it would be quite useful, but I
> > question the need for the boilerplate.
>
> Its certainly possible to put defaults in which would handle the
> "standard" case. My main dislike is having to hardcode behaviour and
> variable handing into bitbake in that case.
>

Not hardcoding *any* behavior into bitbake is how we got into the mess that
we're in, and is likely the source of a large amount of confusion on the
part of our userbase, and is likely the cause of some of the performance
issues as well.  Flexibility is good, but there's a point at which the
benefits no longer outweigh the drawbacks.


> The idea that adding an empty layer.conf file breaks a previously
> working overlay seems counter intuitive too...
>

The layer itself deciding where it goes in the BBPATH is not obvious or nice
or clear to me the way it seems to be to you.  How can a given layer claim
to know where it should go in the bbpath, what its priority should be?  I
think it makes a great deal more sense to let the order/information in
bblayers.conf define that, as the user has direct control over that.  Can
you think of any cases where a given layer could possibly know better than
the user, or where defining the priority via BBLAYERS is insufficient?
 Regarding BBFILES, there's nothing to hardcode.  Add the layer to BBFILES,
let bitbake find the recipes, and you have BBMASK to remove the ones you
don't want.
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics



More information about the Openembedded-devel mailing list