Modify build.yml to include creation of AppImage

[J-Atoche]

No description provided.

[rofl0r]

what's the point of this? we already provide a linux binary, which is equally portable than this appimage (i.e. runs only on hosts with recent glibc and x86_64 cpu).

if anyone considers merging this PR, please use the "squash and merge" button so the commit history isnt spammed with 70 trial-and-error commits.

[J-Atoche]

what's the point of this? we already provide a linux binary, which is equally portable than this appimage (i.e. runs only on hosts with recent glibc and x86_64 cpu).

if anyone considers merging this PR, please use the "squash and merge" button so the commit history isnt spammed with 70 trial-and-error commits.

On Steamdeck the linux binary dont work... im very new on this, if i am wrong You can correct me

[rofl0r]

On Steamdeck the linux binary dont work

can you be a little more specific ? what errors are you getting ?

[Samueru-sama]

Please reconsider providing the appimage instead of proving binaries for linux, even the two big ryujinx forks both recently got appimage builds after the main repo went down.

It has a lot of useful features like zsync updates with appimageupdate and the appimage runtime makes it extremely easy to set up a portable .home or .config since it detects when you have a $0.home directory next to the appimage and sets that as $HOME automatically for example, much better than checking if portable binary you provide has this built in and then having to open the app and go into the settings to set it up the first time.

what's the point of this? we already provide a linux binary, which is equally portable than this appimage (i.e. runs only on hosts with recent glibc and x86_64 cpu).

At bare minimum appimages have to be made on the oldest still supported ubuntu LTS release, which is 20.04 right now to guarantee more compatiblity, however you can also just bundle everything with the dynamic linker and make them work on any linux system, but that takes more time and effort to make: see here

[rofl0r]

before we use appimage to solve a problem, we should first define what the exact problem is and then look for the best solution. there are several issues with the appimage format itself, which you can find when you search for issues opened by me on their tracker.

[Samueru-sama]

we should first define what the exact problem is and then look for the best solution

heh

there are several issues with the flatpak format itself, which you can find when you search for issues opened by me on their tracker.

flatpak is a whole different thing and it isn't portable, also I'm just checking the issues and I can't believe what I'm seeing: #856

This should not be possible, as far as I know flatpak ships its own runtimes which are like distros that give you all the dependencies including the GPU drivers.

With this said, if Desmume only depeds on gtk, sdl and opengl, it should be easy to make a truly portable appimage with the GLX libs included that truly works on any system, gonna do some tests.

[Samueru-sama]

Alright results are promising:

#!/bin/sh

set -eu

PACKAGE=desmume
DESKTOP=org.desmume.DeSmuME.desktop
ICON=org.desmume.DeSmuME.svg
TARGET_BIN="$PACKAGE"

export ARCH="$(uname -m)"
export APPIMAGE_EXTRACT_AND_RUN=1
export VERSION="$(pacman -Q $PACKAGE | awk 'NR==1 {print $2; exit}')"

APPIMAGETOOL="https://github.com/AppImage/appimagetool/releases/download/continuous/appimagetool-$ARCH.AppImage"
UPINFO="gh-releases-zsync|$(echo $GITHUB_REPOSITORY | tr '/' '|')|latest|*$ARCH.AppImage.zsync"
LIB4BN="https://raw.githubusercontent.com/VHSgunzo/sharun/refs/heads/main/lib4bin"

# Prepare AppDir
mkdir -p ./"$PACKAGE"/AppDir/shared/lib \
	./"$PACKAGE"/AppDir/usr/share/applications
cd ./"$PACKAGE"/AppDir

cp /usr/share/applications/"$DESKTOP"             ./usr/share/applications
cp /usr/share/applications/"$DESKTOP"             ./
cp /usr/share/icons/hicolor/scalable/apps/"$ICON" ./

cp -r /usr/share/glvnd   ./usr/share
cp -r /usr/lib/gconv     ./shared/lib

# ADD LIBRARIES
wget "$LIB4BN" -O ./lib4bin
chmod +x ./lib4bin
./lib4bin -p -v -r -e -s /usr/bin/"$TARGET_BIN"

# Prepare sharun
echo "Preparing sharun..."
ln -s ./bin/"$TARGET_BIN" ./AppRun
./sharun -g

# MAKE APPIAMGE WITH FUSE3 COMPATIBLE APPIMAGETOOL
cd ..
wget -q "$APPIMAGETOOL" -O ./appimagetool
chmod +x ./appimagetool

./appimagetool --comp zstd \
	--mksquashfs-opt -Xcompression-level --mksquashfs-opt 22 \
	-n -u "$UPINFO" "$PWD"/AppDir "$PWD"/"$PACKAGE"-"$VERSION"-"$ARCH".AppImage

mv ./*.AppImage* ../
cd ..
#rm -rf ./"$PACKAGE"
echo "All Done!"

The AppImage is 90 MiB but that is the price of having to ship all the libs it needs to have opengl working on any linux system, just tested on alpine (no glibc) after making it on artixlinux and it works, though I haven't tested with actual games.

edit: Yeah it is all working fine, I can't believe I got it right on the first attempt lol

There is only an error about missing gio libs, which is solved by copying all the gio lib dir which not all were deployed for some reason.

[rofl0r]

flatpak is a whole different thing

i was talking about appimage though. fxing typo now.

now, where did you define the problem that appimages or flatpaks are thought as the solution of ?

[Samueru-sama]

now, where did you define the problem that appimages or flatpaks are thought as the solution of ?

No idea flatpaks, not a fan of them.

AppImages are the ones that are portable and can be made truly portable like I mentioned here, a lot of the common appimage tooling is outdated and only focuses on glibc, so it only works on certain distros instead of all, some tooling even still deploys the old appimage runtime which is not static and has a EOL libfuse2 dependency.

So yeah if you want something that just works and want to move it around including with all its configuration files, AppImage is the way but it has to be done right.

[rofl0r]

you still didn't define the problem. is it lack of a distro package, the provided binaries not working, compilation being too complicated ?

i personally wouldn't call something that works only on x86_64 and on distros younger than 4 years portable, especially not with the rise of arm/aarch64.

[Samueru-sama]

is it lack of a distro package, the provided binaries not working, compilation being too complicated ?

None of that is portable.

i personally wouldn't call something that works only on x86_64 and on distros younger than 4 years portable, especially not with the rise of arm/aarch64.

Me neither, but the appimages I'm talking about are not that way either, they bundle the dynamic linker and the GL libs, they should work on any system that has kernel newer than 3.0, like in this example it was tested on ubuntu 14.04 and here I tested it on Alpine linux with working opengl, which has no glibc.

especially not with the rise of arm/aarch64

So it works on any linux system provided your cpu architecture is x86_64 or aarch64 if an aarch64 appimage is made, far far better than the current solutions either way.

you still didn't define the problem

I think I made it very clear that it is to have a portable application that I can just download and run and carry all the dotfiles with as well.

[rofl0r]

they bundle the dynamic linker and the GL libs

last time i checked "the GL libs" are either opensource (mesa using nouveau, etc) or proprietary, and nouveau crashed all over the place, so one would have to bundle proprietary nvidia drivers too... and they alone weigh > 100 mb.

it is to have a portable application that I can just download and run and carry all the dotfiles with as well

if you want things to behave like on windows, maybe you should use that instead.

[Samueru-sama]

they bundle the dynamic linker and the GL libs

last time i checked "the GL libs" are either opensource (mesa using nouveau, etc) or proprietary, and nouveau crashed all over the place, so one would have to bundle proprietary nvidia drivers too... and they alone weigh > 100 mb.

Nope, you can have a hook that downloads the proprietary nvidia drivers for nvidia users, that's how flatpak works and how solutions like conty also work.

Also this would be an nvidia problem and Desmume itself can fall back to software rendering (which the flatpak already has that problem anyway).

it is to have a portable application that I can just download and run and carry all the dotfiles with as well

if you want things to behave like on windows, maybe you should use that instead.

?! This is not like windows but more like dmg images of macos.

There are real use cases to want portable applications, in fact I came here because I was helping an Steam deck user and I was surprised that Desmume didn't have an appimage, but I'm no longer surprised after seeing that type of comments you have made, like arguing that it isn't possible because x86_64 vs arm? And now telling me use windows lmao?