One of the snaps I maintain has a fairly large reusable component: it builds LLVM, and a bootstrap compiler, both from source. The current state of things is here:
This adds quite a bit of repeated effort to the snapcraft build process: there’s really no reason in principle why either LLVM or the bootstrap compiler needs to be built more than once and then re-used for subsequent snap builds. However, I’m not sure what the best way to address this might be, so I’d like to ask for advice and thoughts.
One thought is, if I move the build process to a different CI system from Launchpad (CircleCI is used by the main project behind the snap package), I could bake LLVM and the bootstrap compiler into a Docker image, and then just update the image definition when new LLVM or compiler versions are required. In principle I might even be able to use the Docker images used by the main upstream project.
Does anyone have any advice, thoughts, or experience to share on this kind of use-case and how they dealt with it?
Reawakening this topic, as an idea has occurred to me. Would it be possible in principle to address the problem in the following way?
build LLVM to create a separate library snap package, which need be built only when new LLVM releases come out
use build-snaps to make it available at build time in the app snap package
build the app pointing it to the LLVM install location in the snap
The main objection that I can see is that it would pollute the snap store with something whose existence only needs to be transitional. But I’m interested in how the idea looks to others, and whether there are alternatives I haven’t thought of.
I think build-snaps will suffice, as the library is only needed at build time, it doesn’t need to be staged itself into the final snap. (IIRC the needed components are statically linked into the app executable.)
Question is whether it makes sense to build a whole library snap in this way when it’s only needed by one app snap.