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 \
"
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 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.
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.
I have a large amount of code that I'm running doxygen against. To improve performance I'm trying to break it into modules and merge the result into one set of docs. I thought tag files would do the trick, but either I have it configured wrong or I'm misunderstanding how it works.
The directories are laid out:
root +
|-src+
| |-a
|
|-doc+
|-a.dox
|-main.dox
|-main.md
|-output+
|-a+
| |-html
|-main+
|-html
In addition to 'a' there are other peer directories but am starting with one.
a.dox generates output and a tag file into root/doc/output
OUTPUT_DIRECTORY=output/a
GENERATE_TAGFILE = output/a/a.tag
INPUT=../src/a
main.dox just inputs the markdown file that has a mainpage tag and refers to the other projects tag file.
OUTPUT_DIRECTORY=output/main
INPUT = main.md
TAGFILES=output/a/a.tag=output/a/html
Should this merge or link all the docs under main where I can browse 'a' globals, modules, pages, etc? Or does this only generate links to 'a' if I explicitly cross-reference a documented entity in 'a' from inside of 'main'?
If this should work, any thoughts on where my syntax is incorrect? I've tried various ways to define TAGFILES, is the output directory relative to the main.dox file? To the a.tag file? Or to the a/html directory?
If I'm off base an TAGFILES don't work this way, is there another way to merge sets of doxygen directories into one?
Thanks.
I suggest you read this topic on how I recommend to use tag files and the conditions that should apply: https://stackoverflow.com/a/8247993/784672
To answer your first question: doxygen will in general not merge the various index files together (then no performance would be gained). Although for a part you can still get external members in the index by setting ALLEXTERNALS to YES.
Doxygen will (auto)link symbols from other sources imported via a tag file. So in general you should divide your code into more or less self-contained modules/components/libraries, and if one such module depends on another, then import its tag file so that doxygen can link to the other documentation set. If you run doxygen twice (once for the tag file and once for the documentation) you can also resolve cyclic dependencies if you have them.
In my case I made a custom index page with links to all modules, and made a custom entry in the menu of each generated page that linked back to this index (see http://www.doxygen.nl/manual/customize.html#layout) how to add a user defined entry to the navigation menu/tree.