Re: [Bug-gnubg] Proposed patches to the gnubg sources

[Jim Segrave]

On Thu 03 Feb 2005 (12:08 +0000), Jon Kinsey wrote:
> macherius wrote:
> >
> >I have been playing around with the gnubg sources using Windows and Visual
> >Studio 7.1. I managed to compile both the GUI and the no-gui version using
> >recent libs. No gcc-mingw was involved, only VC++ was used. In separate 
> >mail
> >I'll describe that experiment.
> >
> >While working with the sources minor changes occured. I would be glad if 
> >you
> >found them worthy of being submitted into the CVS, and I loved the idea to
> >be able to compile unmodified CVS sources in my compile environment. Most 
> >of
> >the changes involve compiler problems and warnings.
> 
> I've had a quick look, I've not checked in any changes, hopefully
> ?ystein will do that.  Here's some thoughts:
> 
> * board3d/ drawboard.c font3d.cpp graph.c gtkcolour.c matrix.c misc3d.c
> model.c shadow.c widget3d.c
> - include windows.h before GL headers, otherwise definitions in the Open
> GL headers are missing and yieding compiler errors
> 
> A better(?) fix is to add #include <windows.h> to the gl.h microsoft
> include file - it should be in there and all the other gl.h files I've
> come across are fine.
> 
> 
> * gnubg.c
> - added several #ifdef GUI to avoid linker errors when compiling no-gui
> version
> 
> This is ok, but I think there may be a problem if the settings are saved
> in a command line build, as the window placements will be lost.
> 
> 
> * gtkboard.h, gtktempmap.c, gtksplash.c
> - WIN32 ifdefs to silence warnings with Visual Studio 7.1 and GTK 2.6
> 
> I didn't see any gtktempmap of gtksplash changes and the gtkboard.h
> change was the gl.h fix again.
> 
> 
> * gnubgmodule.h
> - Some more #ifdefs for clashes with defines in Python.h, as they happen
> with Python 2.4 on a Windows system. Probably a more general solution is
> needed, as any platform should have it's individual #ifdef clashes.
> 
> Not sure the existing code was correct as the _HAVE* defines don't seem
> to be used.

No the _HAVE bits can go. All that's needed is to #undef all the
conflicting names between #including config.h and #including Python.h
(or vice-versa)

-- 
Jim Segrave           address@hidden