On 2013-10-21 22:21, Khem Raj wrote:
Ulf

On Mon, Oct 21, 2013 at 9:30 AM, Ulf Samuelsson
<openembedded-c...@emagii.com> wrote:
Trying to build a systemd-gnome-image raspberrypi under Angstrom, with a few
extra layers.

This fails on "xserver-xf86-config_0.1.[bb|bbappend]"

The extra layer has BBPRIORITY = 20.
meta-beagleboard has BBPRIORITY = 8
meta-raspberrypi has BBPRIORITY = 6 (later changed to 120)

BBLAYERS are in the order meta-<extra layer> meta-beagleboard
meta-raspberrypi

It looks like bitbake will select the bbappend in the layer with the highest
priority,
Not really. All bbappends are selected the order or sequence of them
is governed by how the layers line up in BBPATH
Hm, it seemed to work if I increased the BBPRIORITY.

Either method seems to be problematic.

If you build for a certain machine, then you want to define which bbappend to use
regardless of BBPATH or BBPRIORITY.

Maybe bitbake needs to know which meta-layer contains the <machine>.conf,
and always select a bbappend in that layer, over bbappends in other layers.

Otherwise you have to edit bblayer.conf every time you want to switch to a new machine,
which I think is undesirable.




even if that contains a COMPATIBLE_MACHINE clause, which does not
include the current MACHINE.

Is there any way to make bitbake select the correct bbappend file without
modifying the BBPRIORITY?

--------------------------------------------------------------------------------------------
Looks like the xserver-xf86-config for the raspberry-pi fails on

SRC_URI_append_raspberrypi = " file://xorg.conf.d/*"

When I change to:

SRC_URI_append_raspberrypi = " file://xorg.conf.d/10-evdev.conf "

the raspberry pi version completes.

Wildcards are not allowed?
This is a question of fundamental bitbake semantics/syntax for SRC_URI
and nothing to do with bbappends. and I dont think wildcards in
SRC_URI are reliable, so better be explicit about them.

Yes, since this problem occured at the same time,
I thought that I'd mention it as well.
Basically the any image build for raspberry pi involving X is broken then.
/Ulf



--
Best Regards
Ulf Samuelsson
eMagii


_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core



--
Best Regards
Ulf Samuelsson
u...@emagii.com
+46 722 427437

_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Reply via email to