Re: [XBoard-devel] git issues

[Michel Van den Bergh]

h.g. muller wrote:
> > I guess it does not really matter what the user specific 
> > configuration file is except I think it should
> > definitely not be ./xboard.conf. That would mean that the xboard 
> > configuration would depend on
> > the current directory which would lead to all kinds of surprizes 
> > (e.g. engines would use 64M hash
> > in one directory and 128M hash in another directory).
>
> But that is exactly why I like it. I typically run WinBoard through a 
> Tournament Manager, which
> gives me no control on what is on the command line that invoked it.
This seems to be a problem which should be fixed in this particular 
Tournament Manager.... I just checked the documentation of 
"tourney-manager" (which comes with Ubuntu) and it allows
straightforward control of xboard's command line arguments.

> So the only way to control
> the WinBoard settings is to write them in the ini file in advance. And 
> when I run two tournaments
> in paralel, one might need -variant gothic and the other -variant 
> normal. There would be no way
> to do that if all invocations were forced to use the same ini file. 
> (Even for WinBoard I can only
> do it by having two copies of winboard.exe, to have different install 
> directories. Inelegant, but
> at least it works.)
The customary way to deal with this situation is to provide xboard with 
a command line argument to select an alternative configuration file. 
This command line argument could be provided by the tournament manager.

> As to the configuration problem: When the default settingsfile is 
> /etc/xboard/xboard.conf, and
> the user will try to save the settings (and -saveSettingsOnExit true 
> is compiled-in default...),
> it will either work, or he will get an error popup mentioning that 
> this file could not be opened.

> I guess it could be expected from Linux users that they then are smart 
> enough to actually
> create the directory it is supposed to be in, and make it writable to 
> them.
A freshly installed user program that wants to write by default to a 
system configuration file (i.e. one in the /etc directory) would be 
*very* uncommon in Linux (and against the very idea of system 
configuration files which are supposed to be shared by all users).

There is usually system wide configuration file (or directory) created 
at install time and a user specific one created when the user runs the 
program for the first time. For example I have /etc/firefox-3.5 and 
~/.mozilla/firefox-3.5/   (and  I wouldn't expect firefox to dump a 
configuration file in every
directory I run it from....).

In easy cases it is possible to dispense with the system wide 
configuration file.







> We could also provide a "make install" target in the Makefile, which 
> puts the directory there.