The techniques mentioned in that thread are more broadly applicable, but I haven’t been able to implement them in an automated fashion.
This mainly comes down to the fact that the caches I was looking cover all files found in a directory. While we could make e.g. the desktop-gtk3 part build those caches, that will cause problems if some other part also installs files to those directories. As an example, consider the case of gsettings schemas: GTK provides some if its own, but an app might also have a schema.
That’s not to say there’s nothing to be done at the moment. @oSoMoN added the following to the LibreOffice snap packaging:
https://git.launchpad.net/~libreoffice/+git/libreoffice-snap/tree/snap/snapcraft.yaml#n292
This does the following:
- adds a part that runs after everything else that might install to one of these shared directories.
- copy anything that was installed to those directories by other parts from
$SNAPCRAFT_STAGE. - build the caches from the part’s copy of the files.
- stage those files along with the caches.
Unfortunately the ordering primitives don’t make it possible to publish a cloud part that runs after everything else, so you’d need to copy this kind of logic to your own snap to take advantage at the moment.
The longer term solution is for snapcraft to grow some additional scriptlet hooks. The idea then would be to add a scriptlet to desktop-gtk3 that builds the caches in the stage directory after all parts have staged their files. Then things should just work without needing any additional boilerplate like in the LibreOffice snapcraft.yaml.