On 2013-10-27 14:21, Philippe Michel wrote: > The portable version would then be started from a short script that > determines where it is run from, sets the environment variable > accordingly and launches the real executable with -s > %GNUBGDATA\preferences or something similar.
The idea of some form of environment variable isn't a bad one. It seems like it may be a reasonable idea. And as I posted earlier today, relative paths are accepted on Windows. I used . (period) as an example or even ..\somedir . Your issue regarding the paths written to the config the first time things are run can be a bit of a problem, and your idea could overcome this. In my previous experimentation with the -s parameter on Windows I realized that shortcuts to GNUBG (that are on the USB drive) have an interesting limitation. Windows shortcuts do not allow you to specify a relative path to the executable. So when you create a shortcut that is in the same directory as GNUBG on the USB stick it requires you to put in a full path including drive letter into any shotcut you create 9Tryign to add a relative location for an executable is blocked by a windows error). As you point out that drive letter could change. The only way to pass a command line parameter to GNUBG and have it work with relative paths is to create a batch (.cmd or .bat) file that launches GNUBG. For the MS Windows world, I was toying with a solution a long the lines of your suggestion since portability seems to be a feature request there. The idea is to add an option to the installer for those who wish to create a portable install (Some installers have a similar advanced portable install feature). This advanced/expert option would be a page that: a) Asks users if they wish to install to a portable device (ie. USB) b) Ask user for a relative path to install preferences. Default is blank which would translate to a period (.) directory being passed to GNUBG which would result in the base preferences directory being that of the install directory. c) Installer launches gnubg-cli.exe, issues "save settings" command, then exits. This creates a new configuration file (gnubgautorc) but with absolute paths. d) Once gnubg-cli exits the installer reads the config file and does a simple text deletion. All the absolute paths (The install directory base) is simply removed. d) Create a batch file (.cmd) in the install directory that launches GNUBG with the required -s parameter. Once installed a portable user launches the batch file to start GNUBG. This doesn't require changes to GNUBG, but does require the installer to do text substitution on an initially created gnubgautorc resulting in making the data path elements relative (sound files, MET file etc). An environment variable as you suggests isn't a bad idea, but puts the logic in GNUBG. Both ways do handle the portability issue. I don't think portability really applies to *nix given how we do installations, and the required components (shared libraries) are installed separately by the package manager of the platform. On MS Windows the way we do installs we make available all the DLLs and required files inside the GNUBG install directory to help mitigate (but not eliminate) DLL hell, which lends itself to creating portable variations. I don't really think the issue of portability is one that I would extend to non-MS Windows platforms. -- Michael Petch GNU Backgammon Maintainer / Developer OpenPGP FingerPrint=D81C 6A0D 987E 7DA5 3219 6715 466A 2ACE 5CAE 3304 _______________________________________________ Bug-gnubg mailing list [email protected] https://lists.gnu.org/mailman/listinfo/bug-gnubg
