XBoard beta tar ball

[Michel]

I think I found the definitive fix for the gettext issue by looking at the commands executed by "autoreconf".

autogen.sh should be replaced by

Code: Select all

aclocal -I m4\
&& autoheader \
&& automake --add-missing \
&& autoconf

(note the addition of -I m4 to aclocal).

[Michel]

I am now really understanding what goes on. See here

http://www.gnu.org/software/automake/ma ... acros.html

autoreconf looks at the line

ACLOCAL_AMFLAGS = -I m4

in Makefile.am and uses it as a trigger to invoke aclocal with the -I m4 flag.

autogen.sh being a simple minded shell script is not so smart. Therefore
you have to tell it explicitly about the m4 directory.

[hgm]

OK, I will try to digest this.

Something completely different:

In WinBoard, there is the option -autoLogo. This looks in the engine folders given by -fd, -sd for a file called logo.bmp, and if there is one, displays it when the engine plays. (And if one of the players is not an engine, it looks in the sub-directory 'logos' if it finds a file <username>.bmp or <icsname>.bmp, and displays that.)

Now for XBoard this scheme would not work at all: on Linux, compliant engines are all in the same folder, /usr/games (or perhaps distributed over a few more, like /usr/local/games). Now each engine might know where to find its data files, but it won't share that info with XBoard, and it is asking a bit much that XBoard would be able to derive this by itself. The more so because a compliant engine is likely to be installed simply by its command, like 'fruit', so that XBoard won't even have the slightest idea where the binary acually is (except that it is somewhere contained in the PATH).

An alternative scheme would be to put all engine logos in a 'logos' folder belonging to the XBoard private files as well, under a name derived from the engine name, like fruit.xpm or Fruit_2.1.xpm. (Similar to how Polyglot decides on the name of the polyglot.ini files.) This, however, would make it more difficult for engine packages to install their own logo. And logos are not really XBoard specific; it is conceivable that other interfaces could use them too. So it would be nice if there was something like /usr/share/games/logos/100x50, where each engine could install a logo pixmap, and GUIs could look there if they want one.

Do you have any suggestions on this issue?

[Michel]

The suggestion seems fine to me.

I guess there should really be a script

xboard-install-logo <engine> <pixmap>

so that logo's can be installed in a distribution independent way.

The point is that an engine installer should not know the details about how xboard handles logo's.

That leaves other GUI's. I guess there should also be a script.

xboard-find-logo-path <engine>

Ultimately the scripts

xboard-install-logo
xboard-find-logo-path

should be in a package separate from xboard which would be a dependency
for GUI's wanting to use engine logo's...

[Michel]

I guess the script

xboard-install-logo <engine> <pixmap>

should actually start the engine and derive the installation path
for the logo from the engine name. So there should be an argument
saying which protocol the engine uses. Something like

xboard-install-logo --proto uci fruit fruit.xpm

All this is trivial to do in say python....