To GUI developers and Linux engine packagers

[hgm]

Your system is a good one for the user, but it seems a nightmare for the GUI maintainer. You would have to remain aware of every engine, and update each time there is a new one. (OK, that is probably just adding it to some list, but you would still have to update the package.) I am just way too lazy for that!

A much more tricky matter is to encode common non-compliancies, so that the GUI could use work-around options with the engine. I wanted to reserve the 4th line of the .eng file for that (and it could be dependent on the protocol). Some work-arounds I regularly use in XBoard are:

for WB protocol:
Correct the sign of the score on engines that report from white POV
Convert the PV to SAN because the engine uses long algebraic
Overrule the engine's variants feature (e.g. because it forgets to mention a variant it plays, typically "normal")
Tell the GUI it is a WB v1 engine (to prevent needless waiting for feature commands)

for UCI/USI
Delay commands after 'stop' until engine has sent 'bestmove'
Refrain from using 'isready' after the one time at startup
Use 'byoyomi' in stead of 'inc' (for USI)
Prevent use of 'searchmoves' on engines that do not support it
Force pondering, although the engine does not say it can
The engine has a Hash option, but does not report it

It might also be good to list if the engine comes with an own book.