There should be a font class that registers a trigger to run fc-cache. At the moment this isn't a real problem as we only ship a very limited number of fonts, but if someone ships more then the fc-cache generation will be replicated for no reason.
If this is referring to rootfs install time then wouldn't the recent postinstall improvements solve this issue? All there's needed is create an intercept script that will run at the end. The only problem remaining is running fc-cache on host as this is architecture dependent...
Yeah, the motivation was repeated fc-cache calls. As the fontconfig caches are archicture dependent (!!) then a class that sets up an intercept to call fc-cache is the best that we can do. (a class so that it's the one true way of handling font installation)
Created fontcache.bbclass. Patch merged: http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=c31bf6514bdda951b315f16aa640f9d46232c060
Hello, Can you please give us some more info on how to test this? I see the new class added but I don't see where it's used in. I see it used in meta/recipes-graphics/ttf-fonts/liberation-fonts_1.04.bb for example.
I think verifying that the file was integrated and is used by a recipe is all you can do.
fontcache.bbclass is used by meta/recipes-graphics/ttf-fonts/liberation-fonts_1.04.bb which is pulled into core-image-sato-sdk. In master:4da406cd50cf02a63ed76810a670aba1eb561c79 core-image-sato-sdk built correctly for all qemu targets. Verified.