[GRASS5] r.flow: strange compile error M_PI

[Brad Douglas]

On Thu, 2005-06-23 at 17:46 +1200, Hamish wrote:
> > > > > > after an update of the Linux OS, I am no longer able to
> > > > > > compile r.flow:
> ..
> > > > > > aspect.c: In function `aspect_fly':
> > > > > > aspect.c:50: error: `M_PI' undeclared (first use in this function)
> > > > > > aspect.c:50: error: (Each undeclared identifier is reported only once
> > > > > > aspect.c:50: error: for each function it appears in.)
> > > > > > make: *** [OBJ.i686-pc-linux-gnu/aspect.o] Error 1
> > > > > > 
> > > > > > thuille:r.flow[282.26] cat /etc/issue
> > > > > > Red Hat Enterprise Linux WS release 4 (Nahant Update 1)
> > > > > > Kernel \r on an \m
> > > > > > 
> > > > > > It should be in math.h, right?
> > > > > > How to debug such things?
> > > > > 
> > > > > Yes, it should be in <math.h>, but it's not defined on all systems. I
> > > > > don't understand it being missing from your system, either.
> > > > 
> > > > Sorry, forgot to post that. Yes, it is defined:
> > > > 
> > > > grep M_PI /usr/include/math.h
> > > > # define M_PI           3.14159265358979323846  /* pi */
> > > > # define M_PI_2         1.57079632679489661923  /* pi/2 */
> > > > # define M_PI_4         0.78539816339744830962  /* pi/4 */
> > > > # define M_PIl          3.1415926535897932384626433832795029L  /* pi */
> > > > # define M_PI_2l        1.5707963267948966192313216916397514L  /* pi/2 */
> > > > # define M_PI_4l        0.7853981633974483096156608458198757L  /* pi/4 */
> > > >  
> > > > > Generally, I add the following to the source that uses it:
> > > > > 
> > > > > #ifndef M_PI
> > > > > #define M_PI 3.14...
> > > > > #endif
> > > 
> > > I believe I have found the culprit.  M_PI is not defined when specifying
> > > the -ansi compiler option.
> > 
> > Ah! Thanks, Brad. You suggested ifndef statement is now in the
> > code (with copy-paste of pi from /usr/include/math.h).
> > 
> > The problem seems to be solved.
> 
> 
> 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.

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


-- 
Brad Douglas <rez at touchofmadness.com>