Proposal for Linux engine standard

[Michel]

Codecs for example are also generic (they can be used by different applications).

Hence they are _not_ called plugins....

[ilari]

I'm surprised no one has mentioned the freedesktop.org standards yet, because they're followed by pretty much every Linux and BSD operating system. The Base Directory Specification should be kept in mind when installing files, and I think something similar to the Desktop Entry files could be used to store the engine information.

[bnemias]

whatever these are, they are NOT plugins.

I don't see why this became so complex. Just have a directory that contains either one file with a list of installed engines, or a single file for each engine.

It doesn't make sense to me to include multiple configuration details. All you need is the binary location, and the protocol.

Can't you ask the engine the rest by using the protocol?

Regarding other configuration, engines ought to have sensible defaults anyway. It seems strange to put configuration responsibility on a package maintainer instead of the one person who knows how to configure his/her engine properly.

[Michel]

I think a good name for the directory could be

/usr/share/games/agents

"agent" means intelligent entity, which is what chess engines are (in their limited domain of course).

agent sounds much more professional than ai_player and it also more accurate than plugin.

[hgm]

whatever these are, they are NOT plugins.

Funny you give the exact same reference I quoted from above to show they were plugins! But let's not dwell on this issue, as it is really the least important of all our worries. However it is called, the real issue is where to put it, and how to organize it. And what should be in the files is even more important still.

Can't you ask the engine the rest by using the protocol?

In most cases, unfortunately, no. The protocol the engine speaks might be dependent on command-line options, so you could not even converse with the engine if you did not get that right. (E.g. tscp -xboard).

Btw, it occurred to me that we perhaps should organize this by protocol. A GUI will only support one or two protocols, and engines uses a different protocol are certainly of no interest whatsoever to it. So perhaps we should organize it by sub-directories cecp, uci, ucci, usi... The Game or Variant can then be mentioned inside the files.
Often protocol is poorly specified, and the standards that need to be maintained for good operation (e.g. the sign of the score) can only be maintained through GUI options that compensate for non-compliancy with the de-facto standard.

[Michel]

Funny you give the exact same reference I quoted from above to show they were plugins!

I don't think that reference shows chess engines are plugins. If you look at the examples you see that they are all very specific: plugins for a single application. There is nothing that resembles a chess engine <-> gui interaction.

I think "agent" is a much more accurate characterization of a chess engine than "plugin".

[stevenaaus]

I havent followed the thread too well, but i think you're all a little crazy

Chess engines hardly need packaging. It's just not practical.

Considering that they make extensive use of CPU SSE instructions, and also the importance of the 32/64 bit division, why make 4 or more packages of various arch/sse types when all you need is a configure script, and to type "make install".

So talking about package installtion/configuration - which is notoriously complicated on Linux because of the 50 different distros - is a little non-constructive. How many engines would ever support this anyway? A few if you're lucky. That just leaves the other 50 engine i have to manually install myself.

Sure, to properly install engines you need to consider books, tablebases, etc. And Scid could do these things better - especially tablebase detection (which may happen one day) but this is nothing more than a simple "cp" or two after compilation.
Therafter it's a single dialog box in Scid to finish it off. Easy.

To me, "configure" (optionally) and "make install" ARE the best way to install trivial linux software such as chess engines.

[Michel]

50 different distros

Actually there are only two widely distributed packaging systems .deb and .rpm based.

People that choose to run more obscure distros with a different packaging format know how to install things themselves.

[stevenaaus]

50 different distros

Actually there are only two widely distributed packaging systems .deb and .rpm based..

I guess so. But this doesnt address the sharp issue of binary instruction set.

Or the differing use of the filesystems the different distros use. For eg - some totally ignore /usr/games in preference of local or /usr/bin and share.

Others *insist* all configuration files go in /etc.

Also, Debian won't host anything that contains non-GPL components, such as ScidvsPC nalimov table base code, so including books may be problematic.

And gcc and make are generic posix platforms - they also support OS X, FreeBSD and the other unices. HGMs proposal excludes these OSes, while a half decent configure script can handle them.

[Michel]

they also support OS X, FreeBSD and the other unices. HGMs proposal excludes these OSes

Why? They do have package managers no?

And in any case there is nothing that prevents make install from dropping
an engine definition file in (say) $(datadir)/games/agents/...
If you use automake (which is recommended) then all you need to do is to include this file in the DATA variable.

What exactly is distro specific about this?