they also support OS X, FreeBSD and the other unices. HGMs proposal excludes these OSes
Why? They do have package managers no?
Depends what you define as a package manager.
FreeBSD has a ports collection - which is not technically a package manager as they are *ported* not *packaged* - they are not prebuilt.
Mac OS X has a package installer - installing it is not managing it.
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?
And for those OSes that do not come with automake, nor provide any easy way of getting them...?
they also support OS X, FreeBSD and the other unices. HGMs proposal excludes these OSes
Why? They do have package managers no?
OK - i was wrong saying "HGMs proposal excludes these OSes",
but this means there is extra package formats to support beside deb and rpm. OS X is a popular thing, but devs are thin on the ground.
Source and gnu makefiles are supported by virtually every OS beside windows.
And in any case there is nothing that prevents make install from dropping an engine definition file in (say) $(datadir)/games/agents/...
Yes - this is a reasonable suggestion and starting point. But it puts the onus on the engine coder rather than distro packager, and in my experience they wont be bothering with it.
I think you are all much too pessimistic. Once the principle is established I am sure that it will be followed.
For gnuchess it will be a one line change to Automake.am to make gnuchess use this system (the packages would automatically pick this up as the package building software simply uses the build system of the application to create the package).
Linux developers are accustomed to dropping files in appropriate directories (and this is usually done transparently by the build tools, like autoconf or scons).
And if they don't do it themselves then the packager does it, perhaps with a polite suggestion to the "upstream" author, to adapt his build procedure a little bit.
This is how it works. I don't see why it would be any different for engines.
Well, since we're talking about engine configuration, the directory to use should be /etc/chess-engines, or /etc/chess-engines.d (not sure of the .d significance), and each engine (either packages, or from 'make install') should drop a file in there.
If people want to distribute their engine source in a form that is useful for all distros, they would have to deal with differences in the file systemanyway. Because the engines data files would have to go in the distro's equivalent of /usr/share/games/enginename anyway. Compliant use of auto-make solves this trivially ($(datadir)/enginename), and otherwise they probably would allow 'datadir' to be defined as a prefix, with /usr/share as default. And they could do exactly the same for the engine profile.
All that is required is an extra ine in their make-install target:
Well, since we're talking about engine configuration
Not entirely.
The _primary_ purpose of the engine file is to make the existence and capabilities (games/variants) of the engine known to the outside world (GUI's).
Now once the engine has been discovered by the GUI, it still has to be started. So the engine file contains additional information so that the user (GUI) can actually start the engine and talk to it in the correct language (protocol).
A .d directory (as you suggest) is typically for a particular application (like /etc/httpd/conf.d for apache). So /etc/engines.d would not really correspond to the traditional use of .d directories.
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).
I'm fine with that case requiring the user to configure that engine manually in order to make things simpler.
I am still wondering how an alien engine should be defined.
For xboard just putting
Variant = alien
would be sufficient, since the user can load the engine and then discover that there is an option to select a particular variant.
This is useless to icsdrone however (or cutechess-cli) since it is not human so it cannot interprete the options.
So if this is meant to be generic there should be also be variant specific commands.... (or else a different configuration file for every
variant the engine supports).
hgm wrote:But you are probably also fine with having the user edit polyglot.ini files...
If you want to cater to every odd way engines were designed, then it is going to be more complex to do. That's all I am saying. And really, there is no reason to make it that complex to accommodate a few engines that you can't communicate with absent some cmdline args. I mean, it is possible to make engines that don't need that. Most don't need that treatment.
Get the binary location, and protocol. Ask the engines the variants they support, name, author name, etc. cache that data so you only do it once... done.
