[GRASS5] r.flow: strange compile error M_PI

[Markus Neteler]

On Wed, Jun 22, 2005 at 11:40:35PM -0700, Brad Douglas wrote:
> On Thu, 2005-06-23 at 17:46 +1200, Hamish wrote:
...
> > we currently define PI in 31 places:
> > 
> > Note we sometimes use the wrong value (...3116) !
> > 
> > 
> > display/d.vect.chart/bar.c:#define PI  3.14159265358979323846
> > display/d.vect.chart/pie.c:#define PI  3.14159265358979323846
> > imagery/i.gensigset/subcluster.c:#define PI 3.141592654
> > imagery/i.smap/bouman/model.c:#define PI 3.141592654
> > imagery/i.zc/findzc.c:#define PI      3.141592654
> > lib/cdhc/dagstndn.c:#define PI 3.141592654
> > lib/gis/pi.h:#define PI 3.14159265358979323846
> > lib/ogsf/trans.c:#define NPI  3.14159265358979323846
> > lib/symbol/stroke.c:#define PI 3.14159265
> > lib/vector/Vlib/buffer.c:#define PI 3.141592653589793116
> > lib/vector/rtree/gammavol.c:#   define M_PI 3.1415926535
> > lib/vector/rtree/sphvol.c:#     define M_PI 3.1415926535
> > misc/m.cogo/main.c:  #define M_PI   3.14159265358979323846
> > ps/ps.map/vector.h:#define PI 3.14159265
> > raster/r.le/r.le.patch/patch.h:#define  PI    3.14159
> > raster/r.los/radians.h:#define          PI              3.141592654
> > raster/r.out.pov/main.c:#define M_PI        3.14159265358979323846
> > raster/r.random.cells/ransurf.h:#define PI                      3.141592653589793116
> > raster/r.random.surface/ransurf.h:#define PI                    3.141592653589793116
> > raster/r.surf.idw/pi.h:#define PI       3.14159265358979323846
> > raster/r.transect/parse_line.c:#define PI       3.14159265358979323846
> > raster/wildfire/r.spread/main.c:/*float PI = 3.14159; */
> > raster/wildfire/r.spread/select_linksB.c:#define PI 3.1415926535897932
> > raster/wildfire/r.spread/spot.c:#define PI 3.1415926535897932
> > raster/wildfire/r.spread/spread.c:#define PI 3.1415926535897932
> > vector/v.buffer/main.c:#define PI 3.141592653589793116
> > vector/v.in.dwg/entity.c:#define LOCPI 3.14159265358979323846
> > vector/v.label/main.c:#define PI    3.1415926535897932384626433832795029L
> > vector/v.label/.#main.c.1.6:#define PI    3.1415926535897932384626433832795029L
> > vector/v.label/.#main.c.1.7:#define PI    3.1415926535897932384626433832795029L
> > vector/v.transform/trans_digit.c:#define PI  3.141592653589793116
> > 
> > 
> > 
> > There was talk of this on another maling list I follow a month or so back, 
> > some postings from the experts over there follow. (sorry for the long 
> > post, but it is interesting reading if you are into this sort of thing.)
> > 
> > A question: do we want to be strict ANSI ISO C90 compliant or strict 
> > POSIX compliant? Is there any reason to be stricter than POSIX? 
> > i.e. gcc -ansi is good at keeping us honest, but does it go too far?
> 
> Glynn?
>
> > The precision of PI is actually quite important, e.g. for calculations on
> > decimal degrees a little error translates to something quite real on the 
> > ground.
> > 
> > Our use of floats are minimal (vs double), but we'd have to watch our 
> > printf()s, G_warning()s, etc if we start promoting calculations to long
> > doubles via M_PIl and then try to output the result.
> > 
> > -> include in grass6/include/gmath.h   gis.h??
> > 
> > #ifdef M_PIl
> > #define PI M_PIl
> > #else
> > #define PI M_PI
> > #endif
> > 
> > #ifndef M_PI
> > #define PI 3.14...
> > #endif
> > 
> > #define RAD2DEG (180.0/PI)
> > 
> > or some better munge of that order and then edit the above 31 flavours 
> > to use it consistently.
> 
> Currently, "gmath.h" doesn't seem like the best place to define it, but
> it's not the worst, either.

To define it in gis.h might be the easiest way as it should be
already included in most (all) of the indicated files.
 
> Personally, I would work this out via autoconf by doing something like:
> 
> ...
> AC_MSG_CHECKING(for M_PI) 
> mpi=no 
> AC_TRY_COMPILE([#include <math.h>], 
> [ double f = M_PI; ], 
> mpi=yes, AC_DEFINE(M_PI, 3.14159265358979323846)) 
> AC_MSG_RESULT($mpi)
> ...

Is there agreement that this is the best way to go?

Markus