[GRASS5] TODOs for 5.0.0

[Glynn Clements]

Markus Neteler wrote:

> > > Conclusions:
> > > 
> > > If non-GPL code must be removed for the 5.0.0 release, and time is
> > > pressing, I suggest simply removing the offending code, and either
> > > removing dependent programs, or disabling them in src/CMD/lists/GRASS. 
> > > 
> > > I suspect that failure to work altogether is more likely to result in
> > > a program being fixed than failure to comply with the GPL.
> > 
> > A completly agree that we have to remove the code then.
> > Disabling will collide with the GPL.
> 
> Well, disabling important tools like i.pca would be very bad.
> This would upset many users. We should try to migrate at
> least the i.pca and i.[i]fft, maybe look at the others with
> low priority.
>  
> > > I'll work on egvorder/egvorder2 and rand1 initially.
> > > 
> > > I'm willing to work on fft/del2g and jacobi if someone can provide me
> > > with test cases (test data and usage instructions) which exercise the
> > > functions in question.
> > 
> > Thanks for helping.
> 
> I volunteer for testing and suggest to use synthetic data (as proposed
> here in another thread).

Here's an update.

I have re-implemented egvorder2, rand1 and fft. This allows i.fft,
i.pca, i.zc, r.surf.random and i.shape to be built without any
copyright issues.

The outstanding functions are jacobi, gauss and egvorder (the last one
is trivial, but there's no point until jacobi is done). This means
that i.cca, r.surf.fractal and r.surf.gauss still require non-GPL
code.

I wouldn't have a clue as to how to implement gauss, so unless someone
can find an existing GPL-compliant implementation, r.surf.fractal and
r.surf.gauss aren't going to make it into any 100% GPL distribution.

As for jacobi, I suspect that most of the effort is going to be
determining the semantics of the existing function. Jacobi iteration
itself doesn't seem that complex.

I've added configure tests for the FFTW library, which is required by
fft. However, the existing build process doesn't directly support
condional compilation according to the results of configure tests, so
I'll probably need to make fft() a stub function (which generates an
error at run-time) if FFTW isn't available.

I've also done some other stuff, mainly relating to PNG: added
configure tests for the PNG and GD libraries, modified r.{in,out}.png
so that they don't need the netpbm/pbmplus headers, and modified
PNGdriver so that it will output a (non-LZW) GIF file if the GD
library doesn't support PNG.

I'm waiting until CVS is fixed before committing anything.

-- 
Glynn Clements <glynn.clements at virgin.net>