[yocto] yocto beagleboard.conf -- should it not go away?

[Tomas Frydrych]

On 04/09/12 21:25, William Mills wrote:
> I suspect the current issue is just growing pains for a case that has
> not been tested.

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.


> Darren: Is it true you can't get @ the Intel BSP's w/o also getting the
> poky distro defs?  That does seem to mixing things a bit.  (I am not
> claiming meta-ti is clean yet but I want to understand the Intel examples.)

I apologize for getting this wrong, meta-intel is not dependent on
meta-yocto (the meta-yocto bbappends are only apply to the machines
meta-yocto itself contains configs for). 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).

Tomas