2010/2/16 Frans Meulenbroeks <[email protected]>: > 2010/2/16 Richard Purdie <[email protected]>: >> 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
_______________________________________________ Openembedded-devel mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
