Re: [Bug-XBoard] Xboard 4.5.1 install bug Mac OS X 10.6.6

[Arun Persaud]

Hi

> Most certainly not. For one, we don't ever get rid even of obsolete options
> for reasons of backward compatibility.

I'm not sure about this... why do we need to be backward compatible,
especially for things that are not used anymore anyway, e.g. that are
obsolete? I think the thing to do would be to print out a warning,
something like "this option is obsolete and has been superseded by
foobar, please update your script/alias/whatever". Before we get rid of
the option we could also for a certain time (say a few releases), print
a warning saying "this option will be obsolete in the near future,
please use foobar from now on" and then turn the feature off in a later
release. As long as it is well documented I don't see a problem with
this and I think it is pretty common practice in all kind of
software/APIs, etc.

I don't say that we should change our option setting with every release,
but if something is obsolete it should go (in a well documented fashion
of course).

> But secondly, your logic is a bit flawed. This option is crucial when
> Polyglot
> is not in the path even on Linux. And on Windows systems, it usually isn't.

if we need the option than it should stay of course... your earlier
email sounded as if it doesn't matter what's given in this option as
long as polyglot is in the path...

> Plus that Polyglot needs not really be Polyglot, but now is the adapter
> specified in the -adapterCommand option, which could be an adapter
> (like an old Polyglot version) that does need files (like polyglot.ini),
> which it looks for in its startup directory, even if it changes to the
> engine directory after opening them.

ok.

> The second argument of StartChildProcess is normally used for setting
> the engine directory (accordingto the -fd and -sd settngs) before running
> the engine. Only UCI engines use Polyglot.

the only place in the source where it's called with a non empty second
argument according to "git grep StartChildProcess" is one line in backend.c

   err = StartChildProcess(cps->program, cps->dir, &cps->pr);

and I can only find uci.c which sets cps->dir to appData.polyglotDir, so
it's didn't look as if this option was used a lot...

> In fact it is very likely that I will 'proliferate' this option in
> future XBoard versions,
> implementing -polyglotDir2, -polyglotDir3 options for similar use with
> (also new)
> -adapterCommand2,  -adapterCommand3 options, to be invoked by new options
> like -fUCCI / -sUCCI and -fUXI / -sUXI. Although it might be better to
> provide
> synonyms -uciDir / -ucciDir / -uxiDir

not sure if I like adding numbers... can't we just call -polyglotDir
several times on the command line and number it internally (e.g. keep
them in an array or something?)

>> Anyway, we should update the manual, at the moment it says:
>>
>> -polyglotDir filename
>>      Gives the name of the directory in which the Polyglot adapter for
>>      UCI engines resides.  Default: "/usr/local/share/polyglot".

so should we for now just take the 'Default:
"/usr/local/share/polyglot".' out?

cheers
      ARUN