[oe] RFC: Improve our default conf file setup

[Frans Meulenbroeks]

2010/2/16 Richard Purdie <rpurdie at rpsys.net>:
> 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.
>http://picasaweb.google.com/fransmeulenbroeks/Fosdem2010?authkey=Gv1sRgCPfSh7qcjv2siQE#5435938102383709010
> 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?

Sounds quite nice.
Didn't study the class code, but it would be nice if within layer.conf
I could use a relative path, which then is turned into an absolute
path when the layer.conf file is read
That means layer.conf can become very standard wrt BBPATH etc. and you
can even move layers around.

Frans