Is there any way to write a yocto recipe patch that change the DEPEND variable before dependencies checking happen?
For example, I want to change
DEPENDS = "eudev" to DEPENDS = "udev"
But it leads to an issue related to dependencies.
DEPENDS_remove = "eudev"
DEPENDS_append = "udev"
Simply set DEPENDS again in a bbappend for your recipe.
DEPENDS = "udev"
And then you're good to go! If there's more than one dependency, either set DEPENDS to all the original but swap udev or eudev or go for Oleksandr's answer. Still in a bbappend for the recipe:
DEPENDS_remove = "eudev"
DEPENDS += "udev" # or DEPENDS_append = " udev" <= don't forget the leading space!
This will effectively remove eudev from your DEPENDS and add udev to it. Please note that anything appearing in _remove if definitive, you cannot undo it.
Related
I have a distro layer "meta-clayer" from a 3rd party which i do not want to edit.
Is there any method in yocto to append/overwrite some settings in distro.conf in "meta-clayer" by appending it from my custom created layer similar to bbappend method.
Any inputs will be helpful.
Create your own layer "meta-my-layer", inside
meta-my-layer/conf/layer.conf
set
LAYERDEPENDS_meta-my-layer = "clayer"
BBFILE_PRIORITY_meta-my-layer = "100"
#Could be any number higher than the one in meta-clayer/conf/layer.conf
create your own distro in conf/distro/include/mydistro.conf
copy paste the distro of meta-clayer inside it and do your own modification.
Do not forget to update your DISTRO variable in conf/local.conf.
An other way would be to override "settings" in your local.conf file which is the file with the higher priority but this is really not advised and not the best practice.
I want the tar.bz image to be included in the wic image, which is an installer wic image
I have:
IMAGE_FSTYPES += "tar.bz2"
do_image_wic[depends] += "${IMAGE_BASENAME}:do_image_tar"
IMAGE_BOOT_FILES += "${IMAGE_BASENAME}-${MACHINE}.tar.bz2;upgrade.bz2"
so the tar.bz is made first, but... it is not deployed at the point the wic images is made, it is in:
build_output/work/device-type-linux/yocto-image-release/1.0-r0/deploy-yocto-image-release-image-complete/yocto-image-release-device-type-20190611214913.rootfs.tar.bz2
It won't appear in the deploy dir until after image yocto-image-release:do_deploy which naturally occurs after the wic is built (which now fails).
Is there a safe way to access that for the wic imager?
I'm guessing work-shared won't be any good https://www.yoctoproject.org/docs/latest/ref-manual/ref-manual.html#structure-build-work-shared
Is the better way to have a new installer.bb which depends on the yocto-image-release.bb:do_deploy so it can find the pieces and then make its own wic?
One solution seems to involve BBCLASSEXTEND so that I can build bitbake yocto-image-release and bitbake yocto-image-installer by amending the recipe (or a parent class) to include:
BBCLASSEXTEND += "installer"
DEPENDS_installer += "${BPN}"
and in installer.bbclass:
CLASSOVERRIDE = "installer"
and then I can override values with _installer suffix, although there will likely be a lot of work neutralising most of the configuration and methods of the native recipe, because (for now) all I want to build is a wic with the systems own kernel.
No doubt later it will have its own kernel configuration and initramfs anyway as the installer specialises.
This seems nice as there are a variety of images (-dev, -debug, etc) all of which may want an installer. But I still wonder if -installer couples the two too tightly
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.
I have the following snippet, to copy a file as-is to the build dir:
for m in std_mibs:
print("Copying", m)
bld(name = 'cpstdmib',
rule = 'cp -f ${SRC} ${TGT}',
#source = m + '.mib',
source = bld.path.make_node(m + '.mib'), # <-- section 5.3.3 of the waf book
target = bld.path.get_bld().make_node(m + '.mib')
)
I see that this rule, though hit (from the print), the copy doesnt seem to be happening!
I also changed the source to use the make_node as shown, in an example in the section 5.3.3 of the waf book, still no luck! Am I missing something obvious here!?
Also, I have some rules after this, which rely on the copied files, and I tried adding
an intervening
bld.add_group()
I hope that the sequencing will work, if this copy succeeds
If you run the rule once, it will not be run again until source is updated. This is true even if the target is deleted, for instance (which is probably how you were testing.)
If you want to recopy if the target is deleted, you will need always=True, or you'll need to check for existence and set target.sig = None.
Two alternatives:
features="subst" with is_copy=True:
bld(features='subst', source='wscript', target='wscript', is_copy=True)
waflib.extras.buildcopy like this:
from waflib.extras import buildcopy
#...
def build(bld):
bld(features='buildcopy',buildcopy_source=['file'])
cp is not platform independent.
A task_gen object is created, which later will become a Task, that will be executed before process_sources. Don't expect an immediate effect.
Have a look into your out dir, there will be out/${TGT} (not exactly, but ${TGT} path relative to your top directory)
This is totally to be expected behaviour, since you do not want to modify your source tree when building.