But if you are running configure why a cut-down one? What sort of
things
are you leaving out and why? This is an interesting little project.
I cut out everything that depends on the configuration of the GRASS 6
base installation, basically all the things which are user-configurable,
like ODBC, OpenGL and so on and only keep the parts which are
strictly necessary to configure different environments, such as CygWin.
The idea is that external modules will only be able to use functionality
present in the target system's GRASS installation, anyway.
So there is no point in re-configuring all these options over and over
again.
But maybe the approach suggested by Daniel, i.e. using a grass-config
program similar to how e.g. the gnome desktop libraries do it,
is the cleaner approach. I don't know, will have to do som playing
around with different schemes.
However, I think the best way would be to be able to compile external
modules with exactly the same Makefiles used for compilation from
within the GRASS source tree. That way, splitting up GRASS modules into
a number of functional packages would essentially be no more work than
copying them into separate directories and distributing them
in a tar.gz file.
There was a paper in Photogrammetric Engineering & Remote Sensing
a year
or two ago (from CERL, actually) about a new very fast way of
doing
viewshed analysis that sounded like it would be a very nice
project to
implement using a vector graph structure to show direct paths
between
raster cells, and to make calculations using the Directed Graph
library.
Sounds interesting, indeed. However, I am now so well acquainted
with r.cva, that I think I will keep working on that code base
a little more.
Things that I would like to include are probabilistic viewsheds
to account for DEM errors and fuzzy visibility decay functions
for things like atmospheric effects etc.
If you have any relevant information about these, I would be happy
if you could send me some references.