Update build.yml for Linux

[ghost]

Commented code was added to the "build.yml" file. The commented code might be used as a reference.

[anr2me]

Doing ./b.sh && cd build && ~/ppsspp/scripts/makeappimage_32-bit.sh will still built 64-bit version of PPSSPP because PPSSPP detects the running CPU arch (which is x86_64), and ./b.sh doesn't have cross-compiling option i think.

It might be better to create a separate yml file to test (since you're not creating the artifact) AppImage building instead of using build.yml, which reduce the complexity and running time.

Btw, does makeappimage_32-bit.sh need to be run on 32-bit OS? or it can be run on 64-bit OS too? And what is the name of the final output file? PPSSPPSDL.AppImage? or just ./AppRun?

PS: I'm currently working on manual workflow to generate linux build on various archs (running on QEMU) at https://github.com/ANR2MERefork/ppsspp/blob/test_workflow/.github/workflows/manual_generate_ipa.yml (borrowing manual_generate_ipa.yml file for testing as i can only run jobs on existing yml file) Also modify CMakeLists.txt a little bit to detects neon properly https://github.com/ANR2MERefork/ppsspp/blob/test_workflow/CMakeLists.txt

Was planning to add AppImage format too later if all arch supported by PPSSPP can be built successfully and passed the Headless and Unit tests (currently failed on the headless test like cpu/vfpu/convert on non-intel arch, unit tests seems to be okay). PPS: Dealing with musl toolchain on Alpine Linux can be a pain :( i might consider using a different distro that support riscv64 too later.

[ghost]

The commented code was added as it might be used as a reference.

The 32-bit script was previously used on Linux 32-bit.

The 64-bit script was previously used on Linux 64-bit.

I am not planning on making additional contributions regarding this topic.

[Samueru-sama]

Uh oh

@anr2me I was helping sandboxgamedev123 with setting up the appimage, but I see there has been a small problem lol.

I just checked your commits, I don't think you will be able to use linuxdeploy on alpine unless you use their compatibility layer iirc, it has a dependency to glibc (all appimages do unless you bother to use the static runtime with a statically linked program in it, which is basically none, and linuxdeploy itself doesn't use the static runtime anyway).

[anr2me]

Yeah, i just realized that and stopped testing it after using gcompat and still didn't work LOL

On the bright side, i noticed something strange about action runner where doing sudo update-binfmts --disable appimage-type2 (which is supposedly to be one of the workaround i found here) seems to have permanent effects (can't be enabled again without reinstalling the package). I thought each run will have a fresh start, but apparently not, after facing this issue.

I'll probably replace the jirutka/setup-alpine action with uraimo/run-on-arch-action later for a more versatile selection of distro.

[Samueru-sama]

Yeah, i just realized that and stopped testing it after using gcompat and still didn't work LOL

On the bright side, i noticed something strange about action runner where doing sudo update-binfmts --disable appimage-type2 (which is supposedly to be one of the workaround i found here) seems to have permanent effects (can't be enabled again without reinstalling the package). I thought each run will have a fresh start, but apparently not, after facing this issue.

I'll probably replace the jirutka/setup-alpine action with uraimo/run-on-arch-action later for a more versatile selection of distro.

Worth mentioning that go-appimage, which is the other tool that gets downloaded alongside linuxdeploy uses the static runtime and probably can run in alpine with the --appimage-extract-and-run flag, go-appimage can also do the job of linuxdeployqt, however with qt applications I haven't had much luck with it. Maybe it works for the sdl build though.