On Sat, Sep 01, 2001 at 12:43:22AM +0100, Glynn Clements wrote:
Markus Neteler wrote:
> I am testing on CRAY, but...
>
> cc -g -I/home/t3e/fsn/nhdc/nhdcmark/grass/src/include -c fft.c -o
> OBJ.alpha-cray-unicosmk2.0.5.X/fft.o
> CC-11 cc: ERROR File = fft.c, Line = 67
> The indicated directive is not a recognized preprocessing directive.
>
> #warning fft() not implemented; requires FFTW library from www.fftw.org
> ^
>
> Total errors detected in fft.c: 1
> Make: "cc -g -I/home/t3e/fsn/nhdc/nhdcmark/grass/src/include -c fft.c -o
> OBJ.alpha-cray-unicosmk2.0.5.X/fft.o": Error code 1
> cmd-2436 make: Stop.
>
> Sorry for this, but it needs to be modified again...OK. I'll just remove the #warning line; configure should have
generated a warning if fftw wasn't found, and i.fft, i.shape and
r.surf.fractal will appear in error.log.> BTW: Does it make sense to move the remaining matrix functions from
> src/libes/gis to gmath?Probably. lu.c (G_ludcmp, G_lubksb) and eigen_tools.c (G_tqli,
G_tred2) could move to gmath.
Glynn,
thanks for your fixes. Concerning jacobi.c: Is the same functionality
eventually already provided in eigen_tools.c (just guessing, I can talk
to a colleague on Monday)?
The main issue in forming a common vector/matrix library is converting
existing code to use a common format. So far I've encountered four
formats:1. "double **a", zero-based: gmath/eigen.c, gis/eigen_tools.c,
gis/lu.c, i.pca.2. "double **a", arbitrary ranges: r.param.scale
3. "double a[MX][MX]", one-based: gmath/jacobi.c, i.cca
4. "mat_struct *a": la.c
The main problem with using a structure is that most of the existing
code uses "a[i][j]" to access matrices.
Sorry, no idea here (hi developers!). But it should be conform...
Concerning CRAY and directives:
grass-commit wrote:
[...]
Remove #warning from gmath/fft.c
[...]
What about a platform sensitive switch (ifndef __CRAY__) or so to allow
such #warning for all other platforms? Another #warning also in la.c.
On the other hand "configure" is chatting.
Markus