TalkChess.com

[H.G.Muller]

OK, this is useful information. As I have no Mac, and know nothing about Mac OS, I am dependent on user feedback to know about and solve problems. It is the first time that anything like this is reported, and I will surely take it up with the one who created the Mac package.

Having no permission to use the mentioned directories is indeed likely to cause trouble:

/usr/share/games is the directory that according to Debian standards programs in /usr/games should look for their data files. So the Debian package for fairymax does put the fmax.ini file that contains the move-generator tables for all of the supported variants in

/usr/share/games/fairymax/fmax.ini

It could be put anywhere, as long as the hard-coded file name in the Fairy-Max binary would be set to where it is put, through a -DINI_FILE=... compile-time option. (For Windows, for instance, it is placed in the same folder as the binary.) In fact it is even possible to use the standard Linux binary of Fairy-Max by installing it under XBoard with an extra argument in the engine command to indicate the ini file, like

fmax /anywhere/fmax.ini

I kind of dislike that solution, though, because it means you would have to specify the argument also each time you want to run Fairy-Max from the command line.

The directory /usr/local/etc is used to store XBoard's master configuration file, (/usr/local/etc/xboard.conf), which is used to (re)define the defaults for some of the options, including the file name of the user settings file (~/.xboardrc). This is a Debian standard for packages compiled from source. (In their own binary package for XBoard they use /usr/etc/xboard.conf in stead.)

If there are more logical (and less troublesome!) places to put these files on Mac OS, I am open to recommendations. Note, however, that when you would obtain engines as Linux Debian packages (e.g. Fruit, Crafty, Glaurung) they would in general all expect their data files (e.g. opening books, config files) in /usr/share/games, and although they might not be as dependent on these files as Fairy-Max is, it could still mean impaired functionality (e.g. inability to use their books, not being able to remember their settings, etc.)

Note that these are purely engine problems, not directly related to XBoard, which you would encounter under any GUI when you tried to run the particular engine. But of course pretty annoying if they happen to crash XBoard's default engine. Not being able to read its master settings file would not preclude you from running XBoard, but would impair part of its functionality: the default values of all XBoard command-line options would revert to the compiled-in defaults, and saving the user settings would not work at all. (Which is of course just the situation as existed with any XBoard version 4.4.x or earlier, so long-time users might not consider this a crippling problem. But people used to WinBoard would think it pretty bad...)

What would be the best solution here, if we were to make a special compile of XBoard using default file locations tailored to Mac OS?