I have two recipe, One of them is "gstreamer1.0_%.bbappend" and its in meta-petalinux layer and the other recipe's name is "gstreamer1.0_1.16.1.bb" and its in meta layer.
How wildcarding effects recipe lookup in build process ?
Could you please explain which recipe selected when priority of spesified layers are same, and which recipe selected when priority of spesified layers are different ?
Thanks.
gstreamer1.0_1.16.1.bbappend will be applied on gstreamer1.0_1.16.1.bb only.
gstreamer1.0_%.bbappend will be applied on anything that matches the pattern: gstreamer1.0_ + whatever (e.g. version) + .bb.
Related
For example, I am having meta-A/test.bbappend and meta-A/test.bbappend files.
meta-A/test.bbappend priority 10
SAME_VAR = "a"
meta-B/test.bbappend priority 5
SAME_VAR = "b"
DIFF_VAR = "b"
I think SAME_VAR will be "a" but what about DIFF_VAR?
Would meta-B/test.bbappend be completely ignored due to lower priority?
Every layer has its own priority defined in conf/layer.conf as BBFILE_PRIORITY variable. Priority of the layer defines in which order .bbappend files will append on original .bb.
You can check all layers in your project with
bitbake-layers show-layers
and you will also see the priorities.
I am developing a multiplatform project, so it is a mix of different boards with appropriate meta layers. My meta image layer contains some bbappend recipes that are board specific although I would like to stick to single image layer repository rather than having image layer repository for each board.
So is there any way to completely hide/ignore/disable specific bbappend files?
Example:
I have bblayers for var-som-* boards. For such boards I have recipes-kernel/linux-variscite_%.bbapend, so building for var-som-* boards is fine, but problem happens when I build for example for raspberry. Having variscite layer (as well as all freescale set) adds a lot of things to the image I don't want, so I am removing variscite and freescale layers and it creates No recipes available for: recipes-kernel/linux-variscite_%.bbappend error.
Luckily this question has already been answered:
Yocto Dunfell error 'No recipes available for' with multiple machines in single custom meta layer
So for those, who faced the same problem here is quick summary:
Within your image meta repository create a folder structure that DOES NOT match BBFILES directive.
Move your .bbappend recipes there.
Include recipes on per-meta-layer basis using BBFILES_DYNAMIC directive.
Example:
# thats default and commonly used way to import recipes from your image
BBFILES += "${LAYERDIR}/recipes-*/*/*.bb \
${LAYERDIR}/recipes-*/*/*.bbappend"
# "hide" recipes "deeper" within folder structure
# so they won't be included by ${LAYERDIR}/recipes-*/*/*.bbappend
#
BBFILES_DYNAMIC += "\
meta-atmel:${LAYERDIR}/dynamic-layers/meta-atmel/recipes-*/*/*.bbappend \
meta-atmel:${LAYERDIR}/dynamic-layers/meta-atmel/recipes-*/*/*/*.bbappend \
"
My question is about Azure DevOps build pipeline. I wanted my build to automatically triggered when commit changes. So I include the files using Folder/**/* which any files under the folder including under subfolder. But when I commit changes in one of the file, my build does not triggered. But it worked when I use Folder/* instead. Can anyone explain what is the differences?
I think this could be by design. For the path filter, it could only recognize /* and not /**/*.
For paths:
You may include * as the final character, but it doesn't do anything
differently from specifying the directory name by itself.
You may not include * in the middle of a path filter, and you may not
use ?.
This is stated in the Wildcards of this document.
This is now possible as it is written here Support for wild cards in path filters
Wild cards can be used when specifying inclusion and exclusion branches for CI or PR triggers in a pipeline YAML file. However, they cannot be used when specifying path filters. For instance, you cannot include all paths that match src/app//myapp*. This has been pointed out as an inconvenience by several customers. This update fills this gap. Now, you can use wild card characters (, *, or ?) when specifying path filters.
The documentation is still not updated but you can use Folder/**/* in path filter.
I am using the raspberry pi layer and the IMAGE_CLASSES variable is set this way, I checked doing bitbake core-image-minimal -e | grep "^IMAGE_CLASSES".
I want to modify what is set in ../meta-raspberrypi/conf/machine/include/rpi-default-settings.inc, which defines how the image is partitioned. I want to avoid to edit this file from the raspberrypi layer.
# RaspberryPi BSP default settings
IMAGE_CLASSES += "sdcard_image-rpi"
I would like to use my own .class file. I tried creating a layer with a higher priority, the same filename, same location and different content, but still, bitbake -e returns the same content. And of course, this layer has been added in the bblayer.conf.
I also tried to add in my local.conf:
IMAGES_CLASSES_remove += "sdcard_image-rpi"
Again, no change.
Any idea?
I'm not sure I understand your intention. If you want to override a .class file completely, you can place modified version of it in your custom meta layer, and place your custom layer on top of bblayers.conf (your custom meta should be placed before the one you are overriding class from).
BTW: IMAGES_CLASSES_remove += "sdcard_image-rpi" does not look correct: you should either use _append / _remove override or '+=' operator, not both.
To configure a component I need to add --enable-feature into EXTRA_OECONF_somename
So I tried to do:
EXTRA_OECONF_append_somename = --enable-feature
But it did not help. After investigation it was found that the one of the third-party recipe contains the following line:
EXTRA_OECONF_remove_somename = --enable-feature
I can't modify the third-party recipe.
Is there a way to add --enable-feature into EXTRA_OECONF_somename
Thank you.
I'm afraid not. The _remove operations are always applied last so there is no way to undo them. I would say that the original recipe shouldn't be using it - _remove is intended for distro policy where you want to say "I don't care how this item got in the value, just remove it".
For preference the original recipe should instead it should be using PACKAGECONFIG to control addition (or not) of this feature.