search

libretro / RetroArch

Cross-platform, sophisticated frontend for the libretro API. Licensed GPLv3.
http://www.libretro.com
GNU General Public License v3.0
10.34k stars 1.84k forks source link

RetroArch in mac use internal application to store downloadable content #8641

Open ghost opened 5 years ago

ghost commented 5 years ago

Description

RetroArch store a lot of things inside the /Application/RetroArch.app/ app bundle, such cores, joystick profiles, etc.

Expected behavior

For a batter practice, it should use ~/Documents/RetroArch so nothing is lost when you update the application

Actual behavior

Cores, joypad profiles, shaders and every downloaded content is stored inside RetroArch.app.

Steps to reproduce the bug

  1. Download a core or something with update
  2. Everything is stored in /Applications/RetroArch.app/Contents/Resources

Bisect Results

Maybe if, by default, retroarch take a look in ~/Documents/RetroArch/retroarch.cfg first by default, so he'll always use the configuration there. If nothing is stored there, then get the one inside the RetroArch.app and created a new one based on that.

Version/Commit

You can find this information under Information/System Information

Environment information

inactive123 commented 5 years ago

Added this, hope it helps -

https://github.com/libretro/RetroArch/commit/c9caa5c39b9e56a50be5291e6d11ccfacb0f5eda

Tatsh commented 3 years ago

Would rather see this in ~/Library/Application Support/RetroArch. I do not appreciate random items going in my ~/Documents directory.

ghost commented 3 years ago

Would rather see this in ~/Library/Application Support/RetroArch. I do not appreciate random items going in my ~/Documents directory.

Yes, it could be like that too, I just use it as an example because I don't think is practical to embed everything inside the application.

Tatsh commented 3 years ago

Didn't notice your name! I use nearly all your ebuilds for my Retroarch install on Gentoo.

We just added a build to MacPorts, where the .app bundle is read-only, so we had to patch defaults into the code for now.

ghost commented 3 years ago

Oh, thank you. I always try to keep up with upstream (but it's a one man show, but i'm ok with this). Can I help with something similar? Im always willing to help.

Tatsh commented 3 years ago

If you want to port libretro stuff from ebuilds to MacPorts, it probably won't be hard for most of them. Then said port dylibs could go in ${prefix}/lib/libretro just like on Linux (in your ebuilds; games-emulation/snes9x actually puts its so file at ${EPREFIX}/usr/lib64/snes9x_libretro.so).

If you really want a comparison, I have my overlay and my ports:

ebuild: https://github.com/Tatsh/tatsh-overlay/blob/master/games-emulation/melonds/melonds-0.9.2.ebuild Portfile: https://github.com/macports/macports-ports/blob/master/emulators/melonds/Portfile

A more complex example:

ebuild: https://github.com/Tatsh/tatsh-overlay/blob/master/dev-util/ycmd/ycmd-20210425.ebuild Portfile: https://github.com/Tatsh/ports/blob/master/devel/ycmd/Portfile

I use both systems daily and am not planning on switching away from one anytime soon. I came to MacPorts from Gentoo and picked up writing portfiles pretty quickly given my experience from writing ebuilds.