Add ability to save/read files based on XDG specification

[Tatsh]

This adds the option ENABLE_XDG_DIRS to enable following the XDG specification as closely as possible.

This also allows relocating the binary so that it does not have be adjacent to the resources, etc. It can be at /usr/bin/cemu as long as -DSYSTEM_DATA_PATH=... is used when configuring and the resources are stored in that path (items in bin/).

Regarding logs, the XDG specification says to use the state directory but I have never seen a single app do this, so logs go in the XDG_DATA_HOME.

[Tachi107]

Thanks for your work on this! I have a few minor concerns though.

[Crementif]

I've got some notes and corrections (plus it seems like the indentation settings you used is wrong).

I do feel conflicted about merging these changes, so I'll let @Exzap decide if he wants to merge this since these are definitely good changes (thanks!) and are also improve the flatpak support we eventually wanna provide (afaik). But my personal worries are that this is a pretty big departure from Cemu's portable nature on both Windows and Linux and it's mostly aimed for the unofficial packaging efforts that exist atm.

I've already spoken about it in #117 (comment), but to explain why I'd rather wait with this PR for now is because if we don't make our intentions very clear and put at least a damper on this whole thing, it seems like the packaging efforts will continue and that end-users will just end up having a bad experience with an super-early unofficial Cemu package which'll cause them to write Cemu off as a buggy, incompatible experience.

I'd much rather have a focus being put on core issues that the Linux build has at the moment (see our list at the top of #107) and the regressions that Cemu 2.0 has from the previous versions due to all the reworks.

[Tatsh]

I am in no hurry. Users of my overlay understand all the software, especially emulators, is experimental.

[Tatsh]

I've got some notes and corrections (plus it seems like the indentation settings you used is wrong).

I do feel conflicted about merging these changes, so I'll let @Exzap decide if he wants to merge this since these are definitely good changes (thanks!) and are also improve the flatpak support we eventually wanna provide (afaik). But my personal worries are that this is a pretty big departure from Cemu's portable nature on both Windows and Linux and it's mostly aimed for the unofficial packaging efforts that exist atm.

I've already spoken about it in #117 (comment), but to explain why I'd rather wait with this PR for now is because if we don't make our intentions very clear and put at least a damper on this whole thing, it seems like the packaging efforts will continue and that end-users will just end up having a bad experience with an super-early unofficial Cemu package which'll cause them to write Cemu off as a buggy, incompatible experience.

I'd much rather have a focus being put on core issues that the Linux build has at the moment (see our list at the top of #107) and the regressions that Cemu 2.0 has from the previous versions due to all the reworks.

This change should not affect current builds as the original portable functionality remains as long as -DENABLE_XDG_DIRS is not passed (and -DENABLE_XDG_DIRS is only available if (UNIX)). The goal is to have XDG be entirely optional. If this PR does not have the original behaviour when -DENABLE_XDG_DIRS is not passed, then I need to work on it more.

In the long term I do think you should offer both an installer and a portable version for Windows. Windows has equivalent directories for XDG. People only need to be concerned with where their games are generally. I am not sure why they need to be concerned about where the mlc goes? I am considering removing that option altogether in my Gentoo version.

[Anuskuss]

@Tatsh Putting the bin stuff into SYSTEM_DATA_PATH will also put gameProfiles in there, which will prevent a user launching cemu from creating game profiles (as SYSTEM_DATA_PATH/gameProfiles belongs to root). Can multiple gameProfiles be supported or should I just remove it from SYSTEM_DATA_PATH and put it in $XDG_CONFIG_HOME/cemu?

I'd rather wait with this PR for now is because if we don't make our intentions very clear and put at least a damper on this whole thing, it seems like the packaging efforts will continue and that end-users will just end up having a bad experience with an super-early unofficial Cemu package

@Crementif I know you mean well but this is such a short sighted view on the thing. Just don't provide binaries until you think it's ready. Compiling alone is a good enough deterrent for the Linux newcomers. Also, to be honest, regardless what will happen to this PR, the Linux community efforts will continue anyway. The same thing happend when Cemu was Windows-only - the community found a way (through Wine). Even "against the intent" of the developers if you will.

[Tatsh]

@Tatsh Putting the bin stuff into SYSTEM_DATA_PATH will also put gameProfiles in there, which will prevent a user launching cemu from creating game profiles (as SYSTEM_DATA_PATH/gameProfiles belongs to root). Can multiple gameProfiles be supported or should I just remove it from SYSTEM_DATA_PATH and put it in $XDG_DATA_HOME/cemu?

I thought dist game profiles were in bin/gameProfiles/default and the ones created by user were in bin/gameProfiles (normally gameProfiles in portable install). The code is patched here to read default profiles from SYSTEM_DATA_PATH and read user-made/installed profiles from $XDG_DATA_HOME/cemu.

[Anuskuss]

Whoops, I meant $XDG_CONFIG_HOME/cemu/gameProfiles of course. They are properly created there, just not read. Maybe I'm doing something wrong though, will investigate more later.

[Crementif]

Users of my overlay understand all the software, especially emulators, is experimental.

Cemu 2.0 has an unfinished Linux port that'll take probably at least a month to be usable at the current pace. It's not just "experimental". The current Linux "build" is only useful for devs who want to contribute fixes/features or by people who've got a working wine installation and just want to give it a shot.

In the long term I do think you should offer both an installer and a portable version for Windows.

Yes, like I said, we eventually wanna implement this optional but still major breaking change. Also, this would require more work then just a built-time option, and I don't see this Linux PR making any Windows changes. But for now this seems to me like it is just upstreaming fixes for a packaging script which we don't want to support atm.

[Tachi107]

I agree with @Crementif here. While I'd love to package Cemu for Debian (and derivatives like Ubuntu), it is just not ready yet. I'm doing my best to submit PRs that improve the CMake side of things (#75, #112, and more to come...), as I've worked with it a lot, but packaging it now feels, to me, like a mistake; the Linux side of things needs to improve first. Not by patching in distro packages, but by collaborating with upstream and figuring out the best way to handle the existing problems.