Re: yocto beagleboard.conf -- should it not go away?

[Paul Eggleton <paul.eggleton@linux.intel.com>]

On Wednesday 05 September 2012 09:49:11 Tomas Frydrych wrote:
> The simplest fix would be for meta-ti to preppend itself to the path the
> same way meta-yocto does, i.e., in the layer.conf
> 
>   BBPATH := "${LAYERDIR}:${BBPATH}"
> 
> In fact, this is the *only* way that a layer can override any conf files
> in oe-core, which is probably what you always want in a BSP layer?
> 
> Just quickly scanning yocto git, there are a number of BSP layers that
> are configured the same way as meta-ti, so potentially have the same
> problem, e.g., meta-intel, meta-fsl-ppc. (There are other generic type
> layers configured this way too, but I think it's only a big issue for
> BSP layers and distro layers.)
> 
> As long as we are mixing layers that do both prepend and append, the
> layering will continue to be broken in subtle and hard to identify ways.
> I can't think of a practical use case where a layer other than oe-core
> might need to append itself to the BBPATH? If there were no genuine need
> for layers to append to the path, the BBPATH extension could be done
> automatically when including the layer, instead doing manually in each
> layer.conf, giving us some consistency.

It has been considered witin OE to be best practice to append to BBPATH and 
not prepend, the thinking being that then the search path matches the order of 
the layers listed in bblayers.conf rather than the reverse. I'm not sure I 
agree with it (I tend to prefer to list OE-Core first), but that's the 
convention adopted there.

Quite a few people have asked for the items which BBPATH controls (classes, 
conf files) to instead be found in layer priority order. If bitbake took over 
managing BBPATH, that would be a possibility, and as you say it would improve 
consistency at the expense of a little flexibility.

> But you do need meta-yocto for the atom-pc machine, because meta-yocto is
> the BSP layer for that (and should Intel decide to add an atom-pc to 
> meta-intel, it will be broken exactly the same as the beagleboard machine is
> just now).

Some time ago we discussed the possibility of moving the atom-pc BSP to meta-
intel and then copying it back into meta-yocto, once the layer tooling allowed 
for that to be done dynamically. Since the layer tooling is now in place that 
is at least a practical possibility, but I'm not sure if it's still on the 
cards - it still makes sense to me at any rate.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre