问题
I want to add some layers fetch from upstream for a new machine (call it A) mainly just to use the machine A configure file, kernel and u-boot provided from those layers. However, the new layers have several bbappend files (with bb files as well) that the version is different with other machines' layers in my yocto project.
For example, machine A has its own gstreamer1.0_1.8.1.bb and bbappend file. Other machines are using gstreamer1.0_1.6.1.bb. What happens when I build the image for the other machine is that it builds the version 1.8.1 because Yocto will always look for the newest compatible version of package and build it. However, the gstreamer1.0_1.8.1.bbappend file is written specifically for machine A, does not apply to others and causing errors. Not only the gstreamer, there are more.
I got an idea like BBLAYERS_A += "new_layers \ ..." in the bblayers.conf file, but unfortunately it does not work the way I want it to.
Another idea I have is like:
BBMASK_B = "new_layers \ ..."
BBMASK_C = "new_layers \ ..."
BBMASK_D = "new_layers \ ..."
BBMASK_E = "new_layers \ ..."
BBMASK_F = "new_layers \ ..."
BBMASK_G = "new_layers \ ..."
BBMASK_H = "new_layers \ ..."
BBMASK_I = "new_layers \ ..."
...
It doesn't look good to me and I doubt it won't work as well. I think the build procedure is to load the bblayers.conf file first, then the local.conf. Therefore, before knowing what machine it is going to build, the layers are deployed.
My question is how can I make those newly added layers that work with machine A only, but won't get used by the other machines.
回答1:
You should try to make a BSP-layer to only cause any effects if any of the machines in that layer is being used.
In your example, gstreamer1.0_1.8.1.bb, you should add
COMPATIBLE_MACHINE = "^machinea$"
note, it's a regular expression, so by omitting the leading ^ and ending $, you can by mistake match similar named machines.
Also note, I changed your example of machine name A to machinea, as machines needs to be small letters.
If you're adding .bbappend files, you typically have them modify the build by eg.
SOME_VAR_machinea
If you're overriding files, you typically put them in a structure like:
recipes-support/myrecipe/myrecipe/machinea/some-file
In this case, note the extra subdirectory machinea, which will ensure that some-file is only being used for that particular machine.
回答2:
The solution that works for me is to use DISTRO feature from yocto. It is flexible. What I did is to use different DISTRO for machine_A (meaning using a different configuration file for A), then include a MACHINE_A.inc with BBMASK = "" (or BBMASK = "layers that not for A").
In the default Poky DISTRO, inside the bblayers.conf file, I block all layers introduced by machine_A by using BBMASK = "all machine_A's layers".
In the local.conf, I set DISTRO_machine_A = "MACHINE_A", so when building the image for machine_A, bitbake will look into DISTRO and find the configuration file for machine_A, which will reset the global BBMASK to enable layers for machine_A itself (or even to block other layers).
By using DISTRO, I am able to get a separate build environment for different machines while introducing new layers into the project. Kind of like BBMASK_machine_A (BBMASK_machine_A won't actually work as my question described).
来源：https://stackoverflow.com/questions/46226874/machine-specific-layers-in-yocto