Re: RFC: Improve our default conf file setup

[Marco Cavallini <koansoftware@gmail.com>]

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