[oe] RFC: Improve our default conf file setup
Marco Cavallini
koansoftware at gmail.com
Tue Feb 16 11:15:55 UTC 2010
Richard Purdie ha scritto, Il 16/02/2010 11:34:
> Hi,
>
> I've been thinking for a while that our "look for a conf/bitbake.conf"
> approach to finding our configuration is rather dated and inflexible.
> Talking to others I think they feel the same way and its time to take a
> step back and think about what we actually need. I've tried to do this
> and I have a proposal based on what I found.
>
> The fundamental problem currently is that the build directory is not in
> control of what bitbake does. We require BBPATH to be set to some magic
> value, find bitbake.conf, this transfers control back to a single file
> (local.conf) which then further influences things further. The build
> directory has to be combined with the right BBPATH setting.
>
> Furthermore, we have the powerful overlay extension mechanism but when
> adding an overlay, you have to change BBPATH, BBFILES and a load of
> other things to correctly integrate any overlay into a build.
>
> So taking a step back, what's needed is for the build directory to have
> the basic configuration contained within it and no need for some magic
> BBPATH. Overlays should ship with configuration information attached to
> them.
>
> I therefore propose that before conf/bitbake.conf, bitbake looks for a
> conf/bblayers.conf. This file sets a variable BBLAYERS.
>
> BBLAYERS is simply a list of overlay directories to include for the
> given build directory.
>
> For *each* overlay listed, bitbake will then include conf/layer.conf.
> This is the main change in behaviour for bitbake since normally only one
> file of a given name would ever be included but I think this makes sense
> to give us some new functionality.
>
> These layer.conf files are free to do whatever they need such as adding
> paths to BBPATH, BBFILES and so on (I see new variables being added
> which is to be encouraged e.g. extra site files). Experimenting, its
> obvious the one thing you need in a layer.conf file is the layer
> directory name so I've let bitbake set this in the LAYERDIR variable.
>
> LAYERDIR is a tricky thing since you always want to do immediate
> expansion on it since it will change later. This is going to catch
> people out but so be it, it works really well.
>
> The nice thing about this approach is that its in keeping with the way
> bitbake works, but its powerful and easily extensible and uses the
> existing configuration syntax, parser and so on.
>
> I wrote a patch for Poky illustrating how this thing could be used which
> is included below.
>
> Its also totally backwards compatible. If bblayers.conf doesn't exist,
> it uses the old behaviour and you can mix and match them if you're
> careful too.
>
> Does anyone have any feedback on this approach?
>
> Cheers,
>
Richard,
I agree with this proposal, also beacuse I have been doing an intensive
use of overlays.
But I'd prefer a single configuration file containing everything rather
than a myriad of small ones.
BTW the totally backwards compatibility makes me comfortable with your
proposal.
Cheers,
--
Marco Cavallini | KOAN sas | Bergamo - Italia
embedded and real-time software engineering
Atmel third party certified consultant
Phone:+39-035-255.235 - Fax:+39-178-22.39.748
http://www.KoanSoftware.com
http://www.KaeilOS.com
More information about the Openembedded-devel
mailing list