PROTOTYPE: Add a target to build a Linux appimage for an instance.

[iamleeg]

This makefile bundles a GNUstep app, its libraries (base, gui, back, libobjc, and anything else it links), the helper tools (gdnc, gdomap, gpbs, make_services), and a GNUstep.conf file into an AppRun folder and uses that to make an AppImage. That app image is reusable on any Linux with a compatible glibc, Xorg, and the same CPU architecture. Here's EasyDiff, built on Debian 13 (with gcc, gobjc, and latest GNUstep libs from master branches) and running on Ubuntu 24.04 (which doesn't have GNUstep installed):

The system where you run make appimage needs to have appimagetool and ldd installed, in addition to working GNUstep.

I think there's a lot of caveats here, that the maintainers need to think through to decide how to support this properly. You might even decide that the best way to do this is to have a separate tool that lives outside GNUstep-make. Here's a list of the things I thought:

1. The AppImage only works on the same CPU arch as the host build machine, because -make copy all the libs etc from the GNUstep installation it has access to.
2. If we fix point 1, then we could in principle use the non-flattened bundle structure and distribute AppImage files that work on multiple architectures (x86_64, AArch64, more…). The entry point is a script that sets up the GNUstep environment variables then runs the app's binary.
3. This probably falls over for more complex builds, especially aggregate builds. An AppImage expects to bundle a single application with a defined entry point, so a "suite" of related apps can't live in a single image.
4. I doubt distributed notifications and distributed objects work correctly, but I haven't tested.
5. This approach doesn't currently work with alternative GUI backends, or with themes. It could, by bundling them in the AppImage, it just doesn't at the moment.

Generative AI disclosure: I used the pi coding assistant and the open-weights Gemma4 31B model from DeepMind to help me understand GNUstep-make, and to debug many of the runtime issues I encountered.

[fredkiefer]

Sorry, I don't quite understand the intent of this change. GNUstep already has the standalone file system layout, which could be used for this purpose. In which regard is your approach more useful to a user?

[iamleeg]

@fredkiefer the standalone layout would be a good way to solve a large part - but not all - of the problem here, and maybe a better way to do this is to build a script that installs each library into the standalone layout, then the app, then all the other dependencies, then build the AppImage.

The overall goal is to build an AppImage: a single file that contains the app, and all of its dependencies, that would run on any Linux (where the glibc is compatible with those dependencies; although guix goes further and packages everything in the AppImage). That means not just the GNUstep libs and tools, but libobjc, the libs that -base, -gui, and -back transitively link, and any other library that the app brings in via its GNUmakefile. At this point, using ldd to scan for everything and add it to the AppImage, including the GNUstep libs installed from whatever existing layout, isn't a bad choice.