Re: RFC: Improve our default conf file setup

[Richard Purdie <rpurdie@rpsys.net>]

On Tue, 2010-02-16 at 07:16 -0700, Chris Larson wrote:
> On Tue, Feb 16, 2010 at 4:49 AM, Richard Purdie <rpurdie@rpsys.net> wrote:
> 
> > On Tue, 2010-02-16 at 11:58 +0100, Frans Meulenbroeks wrote:
> > > 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
> >
> > This is what the LAYERDIR variable gives us.
> >
> > Having relative paths would lose all context outside the layer.conf
> > file. We could hardcode a list of variables that needed to be processed
> > and so on but LAYERDIR removes all that complexity whilst still letting
> > you move things around.
> >
> > > That means layer.conf can become very standard wrt BBPATH etc. and you
> > > can even move layers around.
> >
> > You should be able to do that with my proposal, the only file that would
> > need changing is bblayers.conf, not the layers themselves.
> 
> Can you explain what the use case is for needing this much control?  I find
> it unlikely that it would be problematic to simply add each layer as a full
> path to a list of layers in a single file, and leave it at that (i.e.
> bblayers.conf).  If site files aren't in the layer, they won't be used.  If
> recipes aren't around, they won't be used.  It seems a bit silly if every
> layer.conf ends up being a copy of every other layer.conf.  And this sort of
> blind copying tends to lead to problems and cruft (just look at distros that
> copy angstrom).

Several reasons:

a) I like the idea of a given overlay shipping with a description in
some form of what it contains. Its intuitive.
b) I don't want to hardcode behaviour in bitbake (see c/d)
c) Are recipes in a recipes or a packages directory?
d) How deep are the paths to the .bb files?
e) What priority are assigned to the layers?
f) Should a given layer append or prepend to BBPATH? 

It also means that if we add some kind of new functionality we have to
update bitbake to add the appropriate variables, or add horrible
anonymous methods to poke around BBLAYERS.

When the alternative is a single .conf file describing a layer, I know
which I prefer even if most might be two lines of boilerplate.

I was also thinking of your recursive bitbake 'abomination' ;-). With
this new functionality, its possible some code in one of the layers
could check ahead and checkout other layers if it noticed they were
missing. We'd need some additional code for that but its an idea in the
back of my mind.

Cheers,

Richard