I wonder if there’s a way from cmake to create a Flatpak release. I currently use the DEB, RPM and TGZ generators to distribute my software and I gather all DSO dependencies by running my own macro get_runtime_dependencies that fixes some issues and sorts out unneeded system DSOs from those actually needed from my application.
I have little to no knowledge of flatpak.and quite honestly, I would prefer to keep it that way. I would, ideally, like to just add CPACK_GENERATOR( Flatpack ) and be done with it.
Any chance of this happening soon for flatpack or for the competing snaps packages?
1 Like
I can’t comment on flatpak, but I can give an opinion regarding snaps (I’m the maintainer of the cmake snap). I don’t know that it makes sense for CPack to support snaps. A snap package isn’t normally just a case of wrapping an already-built set of binaries. Snaps are meant to be built from scratch with tools that ensure binary compatibility. They coordinate setting up and running the build in what effectively amounts to a virtual machine. The snap workflow wraps the build with its own logic and metadata. It’s quite a process. It isn’t meant to work as a post-build step, it controls the whole workflow from start to end.
It is still possible to wrap a pre-built package as a snap, and in fact the cmake snap now does this. But this isn’t really the normal way of doing things. When you take this approach, you are responsible for building your app in a way that it will run everywhere. For most, this means building on a really old machine (choosing an old CentOS version is common, but these days things like manylinux is where I’d suggest people look). And if you’ve already got a release you want to wrap, then there’s not really much for CPack to do. You’re better off just writing a basic snap metadata (snapcraft.yml) and maybe a simple script to stitch things together. If you want to see an example, take a look at GitHub - Crascit/cmake-snap: Builds the official CMake snap
Thank you for your explanation of snaps and flatpaks. It was what I suspected too.
Currently, I use a Docker image of Rocky Linux 8.8 to build my application so I am compatible with RH8.8+ and Ubuntu 20.04+. There are some issues with Wayland with this approach, thou, as the gtk pixbuf share/ files have changed in incompatible ways, needing to be manually edited on more modern distributions (a two line hack really).
I am not familiar with manylinux. I googled it and it seems to be a Python thing. Can you elaborate?
Manylinux is closely associated with python, but it is of interest to C++ developers too because it is really about a base system that compiled code is compatible with. It becomes very important if you’re building python modules from C++, since you end up in a situation where your module libraries (*.so) are loaded in an already running executable. You have no opportunity to influence where any of the module’s library dependencies come from, or even what GCC runtime library gets loaded. All that is controlled by the way the python executable is launched and the RPATH/RUNPATH information embedded in your binary (but even that won’t always be used if the running process already has the dependency loaded in memory).
Why I think this is relevant for C++ folks in general though is because if you’re producing a shared library for C++ code to consume, you don’t know what that consumer will be. It could in fact be a python module, which brings in the whole compatibility thing that manylinux has already solved for you. The fact that it happens to also work nicely for non-python cases is a nice side benefit, albeit the major benefit if you don’t care about python.