Hi Developers,
here some comments on GRASS 5 source code structure
from Brook Milligan (who included thr "auto-conf" for
GRASS compiling).
Cheers
Markus
Forwarded message:
From brook@biology.nmsu.edu Thu Oct 28 16:19:20 1999
Date: Thu, 28 Oct 1999 08:31:05 -0600 (MDT)
From: Brook Milligan <brook@biology.nmsu.edu>
To: neteler@geog.uni-hannover.de
Subject: Re: Announce: new GRASS 5 beta4 on Tuesday, 26. OctoberMarkus,
our plans are to split the GRASS into topic oriented
packages, say (just an idea)The way to distribute shall be via WWW: We want to create a
I hope you will not limit it to WWW; have an ftp server also, please.
Or at least make the real URL of the files well known so that one
doesn't have to go through manual forms and such. Otherwise, you will
be making it needlessly difficult for people like me who want to
package GRASS for automated installation.Also, please establish a well-known naming convention for your files
and change the names WHENEVER the file changes. Last I checked I
found it difficult to tell what was what or whether anything new was
there; downloading huge files and checksuming them is not my idea of a
fun way to figure out if the contents of a file has changed.This can be realized (hopefully) for the next GRASS 5 release,
when the reorganization of the source code is finished. Reason
is that all the libraries have to go into the base package
etc. to avoid dependency problems.Has this really been discussed? Do you have a plan of how the result
should look? Does this mean that you are considering any of my
earlier ideas about replacing all the arcane build scripts with a
well-designed makefile set? Do you need help in designing this?Just a few suggestions to get the design going (if you need them):
- identify common implicit make rules and place them in a single
top-level Makefile.inc (or whatever) included by all others- identify common variable-driven make rules and place them in the
same place; document the variables and what they do- identify a standard set of make targets to be supported by all
makefiles; document the targets and what they do- replace directory-specific makefiles with much simplified ones which
essentially just define the relevant variables- rearrange the code so the library dependencies make more sense.
likely this will mean defining new libraries and mangling the
contents of old ones.- rearrange the application code to use the new libraries
Note, that the standard BSD make rules (e.g., in /usr/share/mk/* on
NetBSD) are already set up to do a large fraction of the common rules
that I expect you will need. To use them in compiling libraries or
programs is usually a trivial matter of defining a couple of variables
and including the relevant makefiles. Thus, if you followed that
model, I think the makefile rearrangements could be quite easy.
Redoing the code structure is really the difficult part, but it would
help if there was a sane build system first.By the way, I didn't get too far debugging the Red Hat config
problems. Only one person responded and I couldn't make too much
sense of the response. Without having ever seen that OS I have
difficulty understanding why it just doesn't work; there isn't
anything particularly odd about the config script as far as I can
tell.Cheers,
Brook
----------------------------------------
If you want to unsubscribe from GRASS Development
Team internal mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'
length: 3949
max: 0