Garth Corral wrote:
Hi!
> There's been some talk recently of removing crafty from the tree. I
> think I can carve out a few moments this holiday weekend to finish up
> the OS X makefile stuff and it makes a difference whether I have to
> deal with crafty or not. Anyone know what the plan is in this regard?
Current cvs does _NOT_ require crafty anymore and in fact
crafty's source was also removed from the cvs. I support
leaving out crafty of scid for some reasons:
- crafty is not GPL. This does not cause an issue with scid
itself but if you want to package scid for a distribution
relying on crafty is a bad thing. (Eg. Debian will not
pack crafty into their normal tree, in their speak crafty
is "non-free".)
- crafty's build is a bit strange, one can indeed have a lot
of fun if one is not by chance using the same system as
Bob. Though crafty's makefile lists a lot of platforms I
know from my own experience that it needs tweaking at
almost every version. There're some compiler switches and
issues, or to put it more politely: crafty uses very much
of "optimised code".
- There are actually some stronger free engines.
- It is another engine to be packed. IMHO Scid should not
contain any engine at all but if it has to, it should be
the bare minimum. As Toga is used for the trainings stuff
and Phalanx is required as well, we already have two
engines that need to be there for scid to work.
- crafty is an xboard engine. Though I like xboard, actually
engine configuration is much easier for the user when
using UCI engines. Config for crafty within scid is hence
pretty limited and it would require some manual tweaking
outside of crafty to get most out of it. Therefore I think
we can preconfigure better using UCI engine(s).
Additionally, most new engines are UCI only, and keeping
some flexibility and the ability to change the main
engines is IMHO an important thing. Most engines (except
crafty) have a very short lifetime.
The first two points are IMHO the most crucial ones. The
licensing stuff is very important as we surely want to bring
back scid as _the_ default chess database and in fact _the_
default chess program for Unix. Making it easy for the
distributions of whatever flavour to package it is IMHO an
important step. Additonally, to fiddle out at every stage
how to set the compiler... And even if you fiddled it out
for gcc 2.95 you have to fiddle again for 3.0 and 3.1 and
4.0 and 4.1 and ... Its really a mess. (E.g. I switched to
using icc for crafty cause there are not that much changes
in icc and Bob is using it resulting in the makefile to be
ok. At least on Linux x86*.)
--
Kind regards, / War is Peace.
| Freedom is Slavery.
Alexander Wagner | Ignorance is Strength.
|
| Theory : G. Orwell, "1984"
/ In practice: USA, since 2001
-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Scid-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/scid-users