Curtis L. Olson writes: > > Norman Vine writes: > > Curtis L. Olson writes: > > > > > > > Norman Vine writes: > > > > this patch have solved the min/max problems > > > > >http://cvs.flightgear.org/cgi-bin/viewcvs/viewcvs.cgi/SimGear/simgear/compiler.h.diff?r1=1.1&r2=1.2&cvsroot=SimGear-0.3 > > > > as long as WIN32 is defined when the header is parsed > > > > > > I assume since you refer to a cvs version, the patch is there already > > > and I don't need to take further action. > > > > Yes ... but note WIN32 *must* be defined when this header is parsed > > Not really sure this is the case unless one uses technique outlined here > > http://seneca.me.umn.edu/pipermail/flightgear-devel/2002-November/013349.html > > > > ie "simgear_config.h" will *not* have been parsed > > That is *really* *really* ugly though.
***agreed***, but it works for me and is the autools 'approved' method to #define symbols that aren't taken care of by autoconf > Does cygwin gcc export some > symbol we can check for to determine if we need to define NOMINMAX. > What if we avoided using min() max() in our code and used slightly > different function names? This is due to a namespace conflict between the Win32API and libstdc++3.2 so AFAICT we are stuck with this until libstdc++ changes > Or, what if we use: > > #if defined(__CYGWIN32__) || defined( MSVC ) || defined( MINGWIN ) etc. > // keep windows.h from #defining min() max() macros > # define NOMINMAX > #endif or simply revert configure.ac to accomodate the WIN32 users of gcc by reinstating the CXXFLAGS="CXXFLAGS -DWIN32" CFLAGS="CFLAGS -DWIN32" constructs when we are configuring for windows Then the current "compiler.h" will just do the 'right thing' Norman _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
