How to use snap for development libraries

snapcraft
1

Hi all,

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.

Thanks in advance!

2

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.

Here you can find the topical interface and a few examples: The content interface

It is quite analogous to the well-known libfoo + libfoo-dev packaging scheme, only with snaps and with a little less granularity.

3

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.

4

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.

Hope that helps :slight_smile:

5

True. @abroekhuis: To ship the library snap integrated into the dependent snap to be used at runtime, you’d use stage-snaps.

The corresponding key is build-snaps, which would mount the library at build time.

6

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.

7

Just to continue on this path for a bit, I get how this works for building/deploying projects using Celix.

But how would a developer use it wrt an IDE and debugging etc? For example, we use CLion a lot.

8

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