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.
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 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 \
"
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 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.
I am working the particle effects in ogre3d for iphone
Ogre::ParticleSystem* sunParticle = OgreFramework::getSingletonPtr()->m_pSceneMgr- >createParticleSystem("Smoke", "Examples/Smoke");
sunParticle = OgreFramework::getSingletonPtr()->m_pSceneMgr->createParticleSystem("Smoke", "Examples/Smoke");
Ogre::SceneNode* particleNode = OgreFramework::getSingletonPtr()->m_pSceneMgr->getRootSceneNode()->createChildSceneNode("Particle");
particleNode->attachObject(sunParticle);
This is my plugin code
# Defines plugins to load
# Define plugin folder
PluginFolder=./
# Define plugins
Plugin=RenderSystem_GL
Plugin=Plugin_ParticleFX
In staticloader also contains this installing manually
#ifdef OGRE_STATIC_ParticleFX
mParticleFXPlugin = OGRE_NEW ParticleFXPlugin();
root.installPlugin(Plugin_ParticleFX);
root.loadPlugin(mParticleFXPlugin);
endif
I have also add the .particle file
I think i followed all the steps
An exception has occurred: OGRE EXCEPTION(2:InvalidParametersException): Cannot find required template 'Examples/Smoke' in ParticleSystemManager::createSystem at /Users/davidrogers/Documents/Ogre/ogre-v1-7/OgreMain/src/OgreParticleSystemManager.cpp (line 327)
2012-03-22 14:06:46.757 iphonesampleOgreapp[23041:207] Applications are expected to have a root view controller at the end of application launch
You need to specify the resource folder(s), too, to be able to use the actual particle scripts. Are you absolutely sure you do this correctly?
Have a look at this tutorial.
I really think that this error message sounds like the ressources are not correctly initialized or -if they are- the particle script is simply erroneous.