#1377: Cacus could/should provide M_PI --------------------------+------------------------------------------------- Reporter: sbrandt | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: Cactus | Version: development version Resolution: | Keywords: GRHydro M_PI --------------------------+-------------------------------------------------
Comment (by hinder):
Confusingly, on another page in the "Mathematics" section of the GNU C Library manual, it is more specific:
https://www.gnu.org/software/libc/manual/html_node/Trig-Functions.html:
The math library normally defines M_PI to a double approximation of pi.
If strict ISO and/or POSIX compliance are requested this constant is not defined, but you can easily define it yourself:
So M_PI is not a part of POSIX, and requiring POSIX would not solve this problem. Apparently, M_PI was removed in C99; it was present in Unix98.
According to http://stackoverflow.com/questions/5007925/using-m-pi- with-c89-standard, the only way to get M_PI is to use compiler-specific non-standard methods. Given this, we have several options:
1. The user defines _GNU_SOURCE or _BSD_SOURCE in their compilation flags, or in some other way arranges that M_PI is available. 2. The thorn writer sets these macros in the source file that needs M_PI, or defines M_PI in their source files. 3. Cactus arranges that M_PI is available by using either of the above methods or defining M_PI in the same way as the GNU C Library if it is not defined already. 4. Cactus defines CCTK_PI in the same way as the GNU C Library.
I prefer 3, as it uses a standard name that many people expect. The only case where this might cause a problem is if somebody is trying to import some external code to a Cactus thorn, and this thorn expects that there is no M_PI defined, and uses it itself. I think this is very unlikely.
On a related note, I have created a page https://docs.einsteintoolkit.org /et-docs/Compiling_the_Einstein_Toolkit where we can start to collect policies and knowledge about compilation flags and optionlists. Erik, perhaps you could run through and correct/extend it?