[GRASS5] r.flow: strange compile error M_PI

[Glynn Clements]

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)

> > > I believe I have found the culprit.  M_PI is not defined when specifying
> > > the -ansi compiler option.

With GNU libc, it's conditionalised upon:

	#if defined __USE_BSD || defined __USE_XOPEN

Using -ansi alone breaks various other things. If you want to disable
gcc language extensions but allow various libc extensions, add
-D_GNU_SOURCE to the compilation switches. If you want X/Open
extensions but not GNU extensions, use -D_XOPEN_SOURCE=500.

There is a list of extension-enabling macros at the top of features.h.

Essentially, using -ansi without any other switches results in ANSI
headers (math.h, stdio.h etc) only declaring those functions defined
by the ANSI standard.

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

We don't want to require anything beyond ANSI C90 without good reason.

Given that defining M_PI etc is trivial, it doesn't make sense for
GRASS to refuse to compile on a platform which doesn't have them in
the system's headers.

-- 
Glynn Clements <glynn at gclements.plus.com>