[Top][All Lists]

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

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

From: Jim Segrave
Subject: Re: [Bug-gnubg] Proposed patches to the gnubg sources
Date: Fri, 4 Feb 2005 01:03:19 +0100
User-agent: Mutt/1.4.1i

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

reply via email to

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