> >
> > 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
> > 
Curtis L. Olson writes:
> > That is *really* *really* ugly though.  

Norman Vine writes:
> ***agreed***, but it works for me and is the autools 'approved' method
> to #define symbols that aren't taken care of by autoconf

Well, not exactly, this is the approved way when you don't have
control over the configure.ac, but since we are the authors of the
configure.ac, we should build a check into configure.ac.

> > 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

The configure script does cause WIN32 to be defined.  However, a
source file needs to include <config.h> to see this definition.  That
is what should be happening.

> Then the current "compiler.h" will just do the 'right thing'

I suppose if you are going north and you want to go east, you can take
three lefts, but you might confuse everyone that is riding along.

I say we take this out of compiler.h, add a check to configure.ac, and
then make sure every affected source file includes <config.h>

I can make the changes to compiler.h and configure.ac and then if
cygwin/gcc-3.2 users can tell me which files are bombing, I can add
#include <config.h> to those ...

Regards,

Curt.
-- 
Curtis Olson   IVLab / HumanFIRST Program       FlightGear Project
Twin Cities    [EMAIL PROTECTED]                  [EMAIL PROTECTED]
Minnesota      http://www.menet.umn.edu/~curt   http://www.flightgear.org

_______________________________________________
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

Reply via email to