System-wide install - datadir, user dirs etc

[sjnewbury]

I was writing a Gentoo ebuild for Arculator and I realised it wasn't going to work because it expects to find its resources in the same directory as the executable. Is there a plan to implement loading/saving from standard system/user locations? (Like PCem does)

I ask because I previously implemented the XDG base directory specification for rpcemu, but the patch was not accepted and I don't want to waste my time with that again.

[sjnewbury]

Hope I didn't come across too passive-aggressive. I would be prepared to do the work if it's likely to be upstreamable. I'm currently cleaning/updating my Gentoo overlays, and have a Gentoo package for RPCemu including my XDG base directory patch if you want to take a look:
https://github.com/sjnewbury/emulator-hacking/blob/main/app-emulation/rpcemu/files/rpcemu-0.9.3-xdg-dirs.patch

[Sophira]

I'm using Arculator on Gentoo myself and I'd love it if there could be an ebuild, but you're right, there needs to be some separation.

I'm currently using a script to compile Arculator which removes the configs, cmos and hostfs directories from the git checkout and symlinks them from a separate external data directory, along with custom arc.cfg and hd4.hdf files.

Unfortunately, it's not possible to do the same with the roms directory, because there are frequent changes made to it by commits. (Specifically, the podules directory and the recent addition of the arcrom_ext file.) Any difference between the Arculator version and the expected contents of the roms folder tends to manifest as a segfault on starting a config.

So to work around that, my script is currently symlinking everything from my data directory's 'roms' directory into the roms directory in the git working directory, to just make sure that the ROMs themselves are in place but without touching anything else. Something like this would also need to be done for XDG support - making sure not to consider the roms directory in the XDG location to be the final location, but to load from both there and the original code's roms directory too.

[sjnewbury]

@Sophira That itself shouldn't be too difficult, if you see my rpcemu patch linked above, it supports both "system" and "user" locations for various files. The filesystem layout is quite similar to Arculator, unsurprisingly given the original author!

I'm spread too thin trying to contribute to too many projects at the moment and can't really take anything else on unless there really is an interest. I'm nearly up to 40 repos on my github, and a lot of those are forks of other projects which I've improved/fixed (or didn't like where they were going - so many projects are moving to the Windows[/modern!?!] model of bundling dependencies) and often upsteam is dead and/or unresponsive. That leaves me holding the bag as the last "maintained" fork!

[drekbour]

expects to find its resources in the same directory as the executable

👍 Was just trying to submit a vanilla packaging for Arch Linux and discovered the same when trying to follow the location guidelines. My target layout was:

/usr/bin/arculator
/usr/share/arculator/roms
/usr/share/arculator/cmos
/usr/lib/arculator/*.so # podules

~/.config/arculator/configs
~/.local/share/arculator/hostfs
~/.local/share/arculator/cmos

These all work with XDG basedir spec assuming it can be implemented in a cross-platform way

[Sophira]

I wanted to make a note here that it turns out that podules which are not built as part of the main library (ie. all podules in the /podules/ directory - aka31, lark, etc.) expect to see their ROMs in the same directory as their respective .so files. I also gather that this is a deliberate design decision; the idea is apparently so that developers can release their own podule code with the ROMs in a single ZIP file, which users can then use by unzipping everything into the podules/ directory.

That being the case, it poses a bit of a difficult problem for system-wide installs. I'm not sure what the best way to solve this would be.

[edit: Also, note that this does not apply to the podules that are built as part of the main library - akd52, colourcard, etc. These podules expect to see their ROMs inside the roms/podules/ subdirectory.]

[sjnewbury]

I'm going to take a look at "back-porting" my rpcemu patch to Arculator this week. As for the podule ROMs, I don't think it will be too much of a problem. In my rpcemu patch it searches multiple locations for the required resource files so they can be stored both system-wide and at user level, and combines the found files giving priority to the users XDG home version.

There is no reason why standalone Podule add-ons can't be packaged and installed alongside a packaged Arculator, or else just dropped into "~/.local/share/arculator/podules". Same goes for the ROMs I would think.

[sjnewbury]

I do think there should be some kind of user feedback when specific ROMs aren't available, and to inform the user to install a package or source the ROMs as required.

Is there a list anywhere of ROMs which can be redistributed, or which are available but unredistributable?

I actually haven't even managed to source all the ROMs for the supported Podules, at least I probably have enough to test whether I can get it working.

[sjnewbury]

Something I should have dealt with in the rpcemu patch is what happens on non-Linux systems. To be fair, I didn't intend the patch to be complete, as is, and hoped for feedback from the rpcemu maintainer, but he was simply uninterested in the patch because of the preference to have all resources just be relative to the emulator executable, as is currently the case which discouraged further development effort.

Two alternative thoughts here.

1. I'm using libxdg-basedir to handle some of the complexities. If it isn't available or disabled at build-time, as determined by configure, then fallback to using paths relative to the executable via #ifdef's.
2. Make xdg-basedir required for Linux builds, and handle Windows and MacOS in a platform specific way, even if that's just static paths or by reading known environment variables.

Obviously, option 1 is much easier for me to implement, and could be extended to support other platforms in the future, it also has the advantage of maintaining compatibility for users, without having to mess around with settings env variables in order to have multiple copies of the emulator.

Option 2 ensures consistency, all builds can be the same within each platform, and there is feature parity between platforms. I'm not able to code for this or test it myself beyond Linux though. This will also add at least one non-optional compile time requirement.

[Sophira]

If it helps, you can find all of the supported ROMs in the binary release package download of Arculator, so go ahead and nab whatever ROMs you need from there!

[edit: Well, I say binary release, but on Linux, Arculator isn't distributed as a binary, just source for that particular version. But the ROMs are still in the release download regardless!]

As for changing Arculator's search directories, I'd really want to hear Sarah's view on the matter - she's the main dev here and the one who's doing pretty much all the work, so she really needs to be on board with the idea since any changes here would probably affect her dev workflow.

[sjnewbury]

@Sophira That's why I really favour my option 1 above. It makes it opt-in. If the configure option is specified and the library available it uses XDG base directories, otherwise no change in existing behaviour. I'd even make it default to "disabled" since it's really only to interest to package maintainers.

[sjnewbury]

Thanks for the heads-up about the ROMs! I wondered what I was missing! I've only ever built from github sources, I had no idea!