Add Linux AppImage generation support

[jstefanelli]

Adds optional AppImage generation via appimagetool on Linux.

Only 1 code change was necessary to make AppImage work:
In Startup.cpp, disable name checking if running from inside AppImage

Other changes are:
Added AppImage.cmake to generate AppDir and AppImage
Includes icon (required for AppImage)

The target to generate the AppImage (which is not build by default) is Launcher_AppImage, and it generates the file Launcher.AppImage in the build directory

---

By creating this pull request, I understand that code that is AI generated or otherwise automatically generated may be rejected without further discussion.
I declare that I fully understand all code I pushed into this PR, and wrote all this code myself and own the rights to this code.

[jstefanelli]

Sorry for the delay. That's waay too big of a file. I think the standard icon sizes for appImages go up to 1024x1024.

[ToasterUwU]

@jstefanelli Thanks for this PR!

Friend on mine is on Linux, cant compile this project because of some weird error that neither of us cant figure out, so an AppImage would be really nice to have. Do you have some basic build instructions for your branch? I would like to test this and build an AppImage for my friend, and while im at it review the PR.

[jstefanelli]

Hi @ToasterUwU, the build instructions are almost the same as usual. For the AppImage you need 2 things: make sure appimagetool is in your PATH, and then, when building with cmake, make sure to set the target to Launcher_AppImage.
In practice:
cmake --build bin -t Launcher_AppImage with appimagetool in PATH

[WiserTixx]

@ToasterUwU

because of some weird error

Could you send this error? If it doesn't compile normally I doubt it will work as an AppImage.

[jstefanelli]

@WiserTixx I'm not familira with GH, I may have hit "resolve conversation" too soon, thought it was a me only thing. Apologies.

[ToasterUwU]

@jstefanelli So i did everything you described i should do, but i get an error that the target Launcher_AppImage doesnt exist.

gmake: *** No rule to make target 'Launcher_AppImage'.  Stop.

I have no prior experience with cmake, so i dont know if its normal that "gmake" is complaining to me instead of cmake, when i ran cmake.

So its either user error, or the target actually doesnt exist.

[ToasterUwU]

I looked over the changed files, and i cant really see anything that would add this extra target, but like i said, no prior experience.

[jstefanelli]

@ToasterUwU CMakeLists.txt lines 35 and 36 in my first commit. The target only exists if appimagetool is found by CMake.

[ToasterUwU]

Mhh interesting. Then it doesn't find it, even tho it is in PATH

Had to do it temporarily in PATH with a wrapper script since appimagetool only exists as an appimage it seems.

[gabriele2000]

Friend on mine is on Linux, cant compile this project because of some weird error that neither of us cant figure out

https://github.com/gabriele2000/scripts-collection/blob/main/beammp-autoinstall.sh

[jstefanelli]

Any update on this?

[DesMS]

I do have to ask: What is the benefit of having an AppImage for something that is already just a single file? AppImages aren't sandboxed and it seems like this just adds unnecessary size due to BeamMPs lack of dependencies as well (Its just gcc stuff which you will already have if you could even run the AppImage)

I know its weird coming from making a standalone installer for BeamMP, but, I was just viewing the pull requests

[jstefanelli]

An appimage over a simple executable includes an icon and is handled better by File Managers (at least on KDE).
Dolphin prompts me to grant execute permissions when double-clicking it, for example. Sharing a raw executable is not really common in Linux land, AFAIK

[DesMS]

Sharing a raw executable is not really common in Linux land, AFAIK

That's because linux doesnt really use executables, linux uses binaries 99% of the time, and they have dependencies that need to be resolved and are sometimes case sensitive, however, it just seems a bit strange to be converting what is already a standalone binary to a standalone binary

But, if you prefer AppImage, you do you and I was just wondering why lol

[gabriele2000]

Guys, I made that script to compile BeamMP using a docker container, that would fix everything.
It would be AWESOME if the github pull action, which basically does something similar, would be integrated in releases.

I am still wondering why it's not the case, why it's not mentioned anywhere, why there are compilation instructions that can work truly at 100% only inside a container (if you test it with a slightly not-expected system it'll fail at the microsoft project).

Linux builds MUST be integrated in the releases, it's a SINGLE executable file which will really work very well.

[DesMS]

Linux builds MUST be integrated in the releases, it's a SINGLE executable file which will really work very well.

This is just wrong lol, dead wrong, this is just a waste of storage most of the time since sandboxing is so much better than that

Installers/buildscripts is the preferred way if you dont want to sandbox

Also, please just read the compiling instructions, most of the issues I've seen aren't from BeamMP, its from Microsoft's vcpkg, try a different version than the release

[gabriele2000]

Also, please just read the compiling instructions, most of the issues I've seen aren't from BeamMP, its from Microsoft's vcpkg, try a different version than the release

Literally my whole point.
I had to create a script, as I said, to create a docker container file (you can find the direct link to my script above), to compile everything without issues (it works perfectly, always) and I found that the action page has what I basically do with the script.
That's why I am saying "include the artifacts in the release page", it's literally what you build and it's literally what to put in Steam for it to run.