Integrate AppImage generation tools into IDEs and build tools and services

[probonopd]

It would be nice if we could make it super easy for developers to produce AppImages. For this, integration into IDEs like Qt Creator and build tools like electron-builder might be helpful. Let's collect tools for which this might be useful here (please feel free to add!).

I am happy to help any upstream IDE or build tool wishing to integrate AppImage generation.

• [ ] Open Build Service
• [ ] KDE Craft "With Craft all you need to do is to provide a recipe for your application, provide it's dependency and then ask Craft to build it for you. Craft provides all the libraries, patches and tools needed to build your application and their dependencies. Craft also provides everything you needed to craft an installer on Windows. The Kate and KDevelop installers where crafted by Craft. It is not only a handy tool for KDE and Qt developers, currently we provide about 106 non Qt libraries and about 54 tools, so each and every developer should be interested."
• [ ] AppImager
• [ ] Make (Makefile target)
• [ ] CMake (e.g., see this LinuxAppImageBuild.cmake)
• [ ] CPack - can do Bundle (OSX only) so it would be a natural fit to make AppImages for Linux!
• [ ] Qt Creator ("For OS X this just involves a small program, 'macdeployqt' (source) that gathers all the required plugins and libraries and builds an OS X bundle ready to install. In my naive mind this seems extremely similar to what is required to build an AppImage and that this program could be modified to become 'appimagedeployqt' so that AppImages could be built from Qt projects with very little effort.")
• [x] electron-builder: GitHub Issue
• [x] Meteor Electron: GitHub Issue
• [ ] GNOME Builder
• [ ] Cerbero: AppImage integration
• [ ] kdesrc-build
• [ ] KDevelop
• [ ] fpm: GitHub issue
• [ ] MXE
• [ ] coffeecutie-automation-tools
• [ ] Godot (game engine; it would be good if the developer could export a game easily as an AppImage; just needs to compile AppImage templates, which are copied, and loads data.pck in the same path as the binary)
• [ ] JHBuild was suggested here, as "it requires only very basic system dependencies".
• [ ] sibuserv "Add support of packaging into Appimage packages (https://appimage.org/)."
• [ ] Kivy
• [ ] Grunt https://github.com/Jesus89/grunt-appimage

[chrisnharvey]

Yes! I love this idea.

How about GNOME Builder?

[probonopd]

Added

[shoogle]

While IDE integration would be very welcome, I think lower-level integration via build systems like Make and CMake would be more useful in practice. Everyone has their personal favourite IDE (or none if they prefer text editors and the command line), so the AppImage build process needs to be IDE-agnostic. The best (most portable) solution would be for AppImageKit to provide a series of generic build scripts that could be called via a special Makefile target. (Here's the target I made for MuseScore.) IDE integration would just take the form of a special "Build AppImage" button that would run the Makefile target.

Note that some build systems (e.g. CMake) support the DESTDIR mechanism for installing to a non-standard location. Take the source code for any program which obeys DESTDIR and do this:

./configure
make
make DESTDIR=$(pwd)/Program.AppDir/usr install

Result: the program is installed to Program.AppDir/usr/* instead of /usr/*

So now all that's needed is a way to add the necessary libraries.

[probonopd]

True @shoogle. Can you help? In the ideal world we would have some sort of cross-compiler system that would use recent versions of CMake and the like to build for mature systems like CentOS 6, debian oldstable etc. to ensure maximum binary compatibility. Right now this is way over my head though.

[cgalvarez]

Hi @probonopd. I've successfully generated the .AppImage from a Meteor project and its related .zsync, but I would like to make it self-updateable.

From your AppImageUpdate README:

You could put appimageupdate (and its dependency zsync_curl) inside usr/bin of the AppImage, and call appimageupdate from within your app and even have a little GUI around it; or reimplement it in the language of your app.

I've already downloaded appimageupdate and zsync_curl to usr/bin inside the AppImage, and added that folder into process.env.PATH (Meteor runs over Node.js), but I have no success when executing the command /bin/sh -c appimageupdate meteor-app.AppImage set "zsync|http://localhost:3000/download/linux/meteor-app.AppImage.zsync". I get the error meteor-app.AppImage: 1: meteor-app.AppImage: appimageupdate: not found. I'm running that command inside the Electron client, which is wrapped as an AppImage.

Should I run it that command just after building the .AppImage over it? Should meteor-app.AppImage in that command be the location of the AppImage executable?

[probonopd]

Hi @cgalvarez and welcome to AppImage.

Please try /place/where/you/downloaded/appimageupdate /path/to/your/AppAppImage set "zsync|http://localhost:3000/download/linux/meteor-app.AppImage.zsync".

[cgalvarez]

Thanks for your help, @probonopd. Took it just after writing the comment.

If I bundle appimageupdate and zsync_curl with the AppImage, then the path/to/your/AppAppImage/ is the location where the downloaded executable is placed. The app contents are mounted in a temp folder at /tmp, but what I am wondering now is right how to get that path of the downloaded AppImage... because the user can place it wherever s/he wants.

[probonopd]

@cgalvarez can you update the AppImage by using AppImageUpdate outside of your AppImage?

I understand that you want to make the AppImage update "itself" without the need for an external AppImageUpdate.AppImage. Correct? In that case, you currently need to bundle curl (at least until someone closes https://github.com/probonopd/zsync-curl/issues/9 - should not be hard), zsync_curl, and appimageupdate. Possibly you might want to bundle appimageupdategui as well, to have a GUI updater.

Then you need to point the updater to the AppImage that is currently being used ("itself"). You can use the environment variable $APPIMAGE for that.

[cgalvarez]

@probonopd Yes, I'tve tested updating my AppImage from outside (from the command line in local) successfully.

You're right. I want to make the AppImage update itself without any intervention, so it should point to itself (what I was poorly saying *wherever the user wants to download it, sorry). Didn't know about the env var $APPIMAGE. Thanks!!

I was getting the path through the command ps aux | grep 'app.AppImage$' when you wrote your answer.

Tomorrow I will git it another try. Thank you very much for your explanations and your promptness.

[hbirchtree]

Hello, I was contacted by probonopd about CMake integration. I did the approach of packaging each executable CMake target by themselves with necessary libraries and data files. Some of the assumptions made could be wrong (such as classifying data only into the categories of executables, libraries and data), but this is what I think works. The parts enclosed in (NOT APPIMAGE_FOLLOW_STANDARD) are irrelevant in this situation. (Because I have different requirements for my applications) Here is the latest version (as of the time of this post) I worked on: Link

[probonopd]

Hello @hbirchtree welcome and thanks for your CMake script. Could you give some step-by-step instructions for people not familiar with CMake on how to use it, e.g., to package a simple "hello world" app like https://gist.github.com/fracek/3323924?

[hbirchtree]

@probonopd here you go: https://gist.github.com/hbirchtree/afada1b4886a79abac3e2771773059e3 To use it:

cmake . -DAPPIMAGE_APPRUN_PROGRAM=${path_to_AppRun_executable} -DAPPIMAGE_ASSISTANT_PROGRAM=${path_to_AppImageAssistant_executable}`
make

After this, the .AppImage will be found in the package/linux-appimage directory (configurable with cached variables)

[probonopd]

Thank you very much @hbirchtree, your help is really appreciated. I have commented on some issues I identified on https://gist.github.com/hbirchtree/afada1b4886a79abac3e2771773059e3

[probonopd]

We should have a deep look at http://code.qt.io/cgit/qt/qttools.git/tree/src/macdeployqt/ and see if the same can be done to generate an AppImage.

[probonopd]

Started to work on linuxdeployqt. Please test, review, and send pull requests, and discuss it in #qt-labs on IRC.

[probonopd]

coffeecutie-automation-tools

Builds for Linux against Steam Runtime Mostly independent of underlying platform Based on Steam Runtime chroot setup (but better) Not fully automated yet Generates standard binaries, can also generate AppImage (support incoming) Has Ninja generator

[probonopd]

CMake's CPack can produce .app bundles and .dmg disk images for macOS, so we should try to get it produce AppImages as well:

https://cmake.org/Wiki/CMake:CPackPackageGenerators#Bundle_.28OSX_only.29

Any volunteers?

[probonopd]

AppImageAssistant has been replaced by appimagetool. Use it instead.

[probonopd]

Now that we have CMake experts @TheAssassin @azubieta do you think we could make an AppImage equivalent of https://cmake.org/Wiki/CMake:CPackPackageGenerators#Bundle_.28OSX_only.29?

[TheAssassin]

You're clearly mistaking "average CMake skills" for "is able to write a CPack module".

[nocnokneo]

I've started the work to add AppImage support to CPack here: https://gitlab.kitware.com/cmake/cmake/merge_requests/2645/

It's definitely not polished yet but it's still usable for early testing. I'll try find time to get it cleaned up and into the next CMake release.

[TheAssassin]

Very cool. Will check it out more detailedly soon, but at a first glance, this looks quite good for an alpha version.

You should check out https://github.com/linuxdeploy/linuxdeploy as a (more modern and flexible) alternative to linuxdeployqt. linuxdeploy is less monolithic, it only bundles binary dependencies and a few auxiliary data (like desktop files, icons, soon probably even AppStream). It features a powerful plugin system, allowing users to add additional functionality, like e.g., bundling Qt dependencies. AppImage creation itself is a plugin. Environment variables are used to configure plugin behavior. You can ship custom AppRuns with a parameter, etc. etc. etc.

I hope that shows why it's a lot more flexible than linuxdeployqt. Oh, and btw, linuxdeploy is way better tested.

[nocnokneo]

Thanks for the tip. I wasn't aware of linuxdeploy. I'll check it out when I get a chance. Eventually the AppImage CPack generator could support multiple tools depending on what it can find on the system, but initially it probably makes sense to keep it simple and support just one (linuxdeploy sounds like the best option)

[azubieta]

@nocnokneo This is really great news! We will love to help you, please drop by the appimage channel at freenode if you need anything.

[probonopd]

Welcome to AppImage, @nocnokneo. Great work!

[melroy89]

AppImage within Cpack would be ideal!

[probonopd]

Check out

• https://gitlab.kitware.com/cmake/cmake/-/issues/18782
• https://gitlab.kitware.com/cmake/cmake/-/merge_requests/2645

(I don't really know anything about it, CMake is a $UNKNOWN $MYSTERY to $MYSELF).

[Shatur]

Currently can integrated with CMake by using CPack External Generator.

You can take a look at this gist for an example.

This is how I personally integrated it into my Qt project.