[oe] RFC: Improve our default conf file setup

[Frans Meulenbroeks]

2010/2/16 Frans Meulenbroeks <fransmeulenbroeks at gmail.com>:
> 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
>
Oops apolgies for accidently pasting in the link to my fosdem pics.
FM