Portable Mode - Dummy File (amiberry.portable) to indicate defaulting to local folder structure/relative paths

[RodimusFVC]

Per our discussion in Discord -

Having a flag file to cause a defaulting of behavior to a full portable mode without the need for environment variables, creation of additional paths/confs in the home folder, etc.

If this means moving the amiberry.conf file out of the /data folder and under the binary, that's fine too. As long as I can drop the folder anywhere and click and go - this is a satisfied requirement.

[giantclambake]

I actually touched on this in an EAB post ; I saw it as a compile time aspect .... I'm unsure as to what the 'proper' resolution is here ;)

[midwan]

@RodimusFVC
I've created a new branch with a possible fix, along the lines of what we discussed.
Can you give it a try and see if that works as expected for you?

[RodimusFVC]

@RodimusFVC I've created a new branch with a possible fix, along the lines of what we discussed. Can you give it a try and see if that works as expected for you?

Sure, I'll give it a quick compile and test on my main machine today.

[RodimusFVC]

Tested the following :

• created amiberry.portable in folder and launched amiberry - passed
• moved entire folder with amiberry.portable to a different mount point and launched amiberry - passed
• tried amiberry in a 'new install' scenario with no configuration, but with the amiberry.portable file - passed (all folders defaulted to current path)

Things I noticed and would like your opinion on:

1. When in portable mode, config files are still written using fully qualified paths - should this be changed to be a relative/local path when in portable mode?; eg using ./harddrives instead of /mnt/Emulation/Amiberry/harddrives ?
2. When in portable mode, and the conf folder does not exist, Amiberry simply doesn't write out amiberry.conf/amiberry.ini/themes folder - should this folder also be created?

Everything else works as expected and seem perfect! :) If you want to ignore or track these other two items separately, I can close this issue, or we can fix them in this stream.. or ignore them. Up to you!

[RodimusFVC]

I actually touched on this in an EAB post ; I saw it as a compile time aspect .... I'm unsure as to what the 'proper' resolution is here ;)

The reason I suggested this solution was due to this being used by several other tools that I've used in the past - this also means that you don't have to recompile to gain the benefits of this behavior. Many people will simply use the packaged version, but if you had a zipped copy - then it just simply works. For me, the way I copy Amiberry around from device to device (wherever I'm currently working gets the latest copy) - having this portability is a lifesaver. :)

[midwan]

I've updated the branch, with logic to create the conf dir if it doesn't exist. This should only apply in portable mode, as in other cases we make sure that it exists anyway.

Regarding relative paths: not such a simple change, as much of the code related to that comes from WinUAE, and I'm trying to keep things in-sync between the two projects, so merges can be easier. I think we'll leave that for later.

[RodimusFVC]

I've updated the branch, with logic to create the conf dir if it doesn't exist. This should only apply in portable mode, as in other cases we make sure that it exists anyway.

Regarding relative paths: not such a simple change, as much of the code related to that comes from WinUAE, and I'm trying to keep things in-sync between the two projects, so merges can be easier. I think we'll leave that for later.

Fair enough. I've always wondered why WinUAE did that, considering it also supports portable installations. I had to manually edit the configs every time... so I'm used to doing it. I'll close this out! :) Thanks midwan!

[midwan]

Wiki updated accordingly also: https://github.com/BlitterStudio/amiberry/wiki/Amiberry-directories