gnushogi-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnushogi-devel] Support for XBoard protocol


From: Yann Dirson
Subject: Re: [Gnushogi-devel] Support for XBoard protocol
Date: Sat, 15 Feb 2014 16:48:21 +0100
User-agent: Mutt/1.5.21 (2010-09-15)

(CC'd gnushogi-devel)

On Fri, Feb 14, 2014 at 05:48:24PM +0100, address@hidden wrote:
> Op Zo, 26 januari, 2014 5:44 pm schreef Yann Dirson:
> >
> > You can generate it with "make win32/Makefile", which is what "make
> > dist" calls.
> >
> 
> This works, although I must admit I don't quite understand why. After
> "make dist" there was a Makefile in the tar ball, and when I unpacked it
> on my Windows machine and ran "make gnushogi" in the win32 directory under
> Cygwin I did get a gnushogi.exe and pat2inc.exe. (No idea why I got the
> latter. I did not specify it as a target, and I don't see a dependency of
> gnushogi.exe on it in the Makefile. But I don't really know how to read
> makefiles.)
> 
> The gnushogi.exe runs as a native Windows binary. It does not recognize
> the command "xboard", though. So I could not test it any further.

Hm, yes, no xoard patch is part of "maint" or "master" yet, and recent
versions of wip/xboard are based on master.  I just rebased the oldest
version I could find for an old "maint" on current "maint", and pushed
it as wip/1.4+xboard.

OTOH, what really matters those days is wip/xboard (which, modulo the
bug that shows in minishogi, and other possible bugs, is the version
that should land into master soon).

> I am a bit worried about the placement of GNU Shogi's data files. For
> distribution as a WinBoard binary package the data files should be in the
> package subtree. Normally I would want them in the same directory as
> gnushoi.exe, as making separate subdirectories bin and lib with only a
> single file in them is a bit over-kill. But that is not a big deal. I
> guess the current Makefile would do that when prefix is defined as ".".
> Currently the makefile does define it as /usr/local, which of course would
> not exist in Windows.

Right, it would be better to have a install-root-independant (aka
"portable" in the Windows world) binary.  Good point.

I wonder if such a support should simply not be part of autotools -
all the --libdir stuff and friends really does not look designed to
allow this easily.  I guess we should look at the various free
installers, they should have least provide guidelines, if not
solutions ready for use.

Best regards,
-- 
Yann



reply via email to

[Prev in Thread] Current Thread [Next in Thread]