I tried looking for some docs/info about this, but not sure what to look for. Any pointer would be welcome!
What I want to do is to create a snap for a project that contains a framework for use in development. Looking at the docs, creating a snap doesn’t seem to be too difficult, but I am uncertain about how users can use the snap in their own development.
The project provides several libraries as well as a CMake config which provides the user with several CMake functions to be able to use the framework.
The user has to create a CMake project, and link the libs as well as use the CMake functions to be able to build an application with it.
Is this feasible using snapcraft? If so, how would the user build everything? In my understanding, the snap is build using a fixed set of libraries, which are not necessarily available for development on the users environment.
I think want you want is mostly the platform snap model, e.g. gnome-3-34-1804 and gnome-3-34-1804-sdk. One is used when running the snap, so the executable finds its libraries, the other is used at build time to provide pkg-config and CMake related things.
You can look at how the gnome-3-34 sets things up for inspiration.
Lastly, you’ll want to request auto-connection for your platform snap, so people can use it without any manual steps needed after installing a consumer snap.
So if I understand things correctly, in the snapcraft file for my project I would need to add something like:
slots:
apache-celix-2.2.0:
interface: content
read: /
And in a snap for a project using celix, something like this is needed:
plugs:
apache-celix-2.2.0:
interface: content
target: $SNAP/apache-celix
After this, in the dependant snap, celix is available and the project can be build.
I’d just add that you don’t necessarily need the “split”. It is useful for GNOME libs, because there’s a lot of them, and a lot of snaps using them.
Your library, including headers and such, could just live in a snap that the dependant can add to their build-snaps:, but also include the library itself in their snaps. The disadvantage, then, is that those dependants duplicate the library, and need rebuilding to include a new version. The advantage is that it’s simpler, and if the snaps come from different publishers, you don’t need to ask for auto-connection of that interface.
Just remembered one more advantage: ABI compatibility would be a build-time problem, not a runtime one. That’s why it’s gnome-3-34 and not simply gnome - it has to remain ABI-compatible with any snaps built against gnome-3-34-sdk, otherwise those snaps would break on a refresh of the runtime snap.
If you install the snap, its contents will be available at /snap/library/current. With a bit of configuration, CMake should be able to find those. E.g. by modifying PKG_CONFIG_PATH