[GRASS5] Code structure

[J.C.M. van der Kwast]

Hi list,

In my endeavor to create good documentation, I've now started to analyze 
the code (grass6). I do this by analyzing the doxygen tagfile, which 
works the same as etags, I think. Because doxygen can't handle the link 
between a function prototype, as defined in a header, and the actual 
function, I've started analyzing the functions, so a hard coded link can 
be provided manually. Now I stumble over the grass code structure.

First off, in the directory $grass_sources/include there's a file 
cdhc.h, which is the same as $grass_sources/lib/cdhc/cdhc.h, what is the 
reason for this? (btw can anyone tell me what this library does, it 
seems to have to do with projections)  (btw giving most problems, 
estimated 25 of 71 cases in include and libs, total functions with 
prototypes = 1240, so actual count is about half)

Secondly, in some cases, a function is prototyped in 
$grass_sources/include/$file.h, as follows:

    int function (char *);

and then later locally in $grass_sources/lib/library_group/$file.h as:

#include $grass_sources/include/$file

     int function ();

Seems to create unnecessary redundancy, especially because in most 
cases, a header to a library group, is not used outside that group, but 
I could be mistaken. Can somebody explain? (hint example, follow 
G3d_fatalerror)

Also doxygen will make links for standard c library functions, for which 
you will search to death, if you don't know them, although they are 
simply recognized in my script, because they are not defined in any of 
the headers. (needs manually description, ie eg \brief stdlib)

I'll hope to get a final index ready, with all the functions, structs, 
unions, typedefs, enums, and where they are used soon. But alas, I'm not 
being paid for this, so time is limited.
Also still working on the latex(==pdf) version, as by request.

Still working on a general document to explain the big red line through 
the code and my doxygen bash script, as well trying to come up with a 
general gui system.
For the latter I've done some exploring, and my first choice would be 
gtk+. But generally some kind of lib must be devised which can feed the 
conversion between X and the gui lib, may it be QT, wxPython or 
whatever, this I've seen in other projects. Maybe it is there already, 
but I see some modules implementing it different ways, especially when 
interactive.

Lately I've got the feeling that a genuine discussion about elementary 
functioning and coding structure is due (Thierry Laronde was on this 
path, but chose another one, which is regrettable as he is a much better 
programmer than I am) . For the actual coders, although I'm not one of 
them yet, please do not be offended by this. I have a passion for this 
project, and would like to see, it becoming the best around (in some 
cases, especially raster based, it is the best, vector  based is coming :)).

Last remark in all my ramblings, please comment, give advise, correct me 
where I'm wrong etc. I'm still learning!

Greetings,

Joris van der Kwast