Re: [PATCH 1/2] Fix segfault with 'Game List Tags' dialogue

Thomas Adam schreef op 3/21/2015 om 2:06 PM:
> The winboard/makefile.gcc file suggests that it can be cross-compiled, yet
> it's clearly not received any love for sometime, since there's calls to
> -mno-cygwin which have been deprecated options to GCC---and in more recent
> versions have been completely removed (hence 'make -f makefile.gcc' now
> errors out).
The WinBoard binary that I distribute is compiled by gcc 3.4.4 for that 
reason.
Newer versions indeed did not seem to work, and I never could figure out 
how to
produce a native Windows binary with those. So I stuck to 3.4.4, which 
does the job fine.
> So although I could install the msys toolchain on my workstation, I am still
> dubious whether I'll be able to cross-compile at all.  Even if that were
> successful somehow, is this testable under wine or some such, or are such
> tests misleading?
I never tried to run WinBoard under wine. As my primary machines are all 
Windows,
(running Linux only in a VirtualBox) there never was any need.

> It sounds to me from what you're saying that the coupling between the
> backend and Winboard might still be a little too tight---that is, how much
> of the WIN32 code has actually been shifted into winboard itself?
> Obviously, changes to the backend, if that separation were completely true,
> ought to reduce the chances of breaking Winboard.
The front-ends originally contained lots of game-specific code, 
basically duplicated.
A few years ago I rewrote the XBoard front-end, cleansing it as much as 
possible
of anything game dependent, for the purpose of making it more easy to 
port the
true front-end to another widget set. (Which we eventually did: GTK.) 
This led to
the origin of the files menus.c, dialogs.c, draw.c, board.c, 
ngamelist.c, nengineoutput.c etc.,
which contained the platform-independent stuff. But the WinBoard 
front-end still
contains its own code for doing exactly the same.

I think the main point where you have to be careful is when you would 
alter the
prototypes in #included headers like backend.h and frontend.h, as the 
WinBoard
front-end #includes those too. So things like changing char* to char[] 
or adding
const qualifiers will almost certainly cause conflicts when compiling 
WinBoard.

> I don't like the thought of developing for XBoard, knowing that it has the
> ability to break Winboard, so anything you can suggest to me to reduce this
> likelihood is much appreciated.
I think that as long as you don't alter the prototypes (other than in 
style), and don't shuttle
functional code between files shared with WinBoard to files only used in 
XBoard,
you should be OK. When in doubt, it is easy enough for me to try if it still
compiles under Cygwin and let you know if there are problems.
> Thanks!
>
> -- Thomas Adam
>
>