[GRASS5] Comment on source code structure

Markus Neteler neteler at geog.uni-hannover.de
Sat Oct 30 12:25:23 EDT 1999

Hi Developers,

here some comments on GRASS 5 source code structure
from Brook Milligan (who included thr "auto-conf" for
GRASS compiling).



Forwarded message:
> From brook at biology.nmsu.edu Thu Oct 28 16:19:20 1999
> Date: Thu, 28 Oct 1999 08:31:05 -0600 (MDT)
> From: Brook Milligan <brook at biology.nmsu.edu>
> To: neteler at geog.uni-hannover.de
> Subject: Re: Announce: new GRASS 5 beta4 on Tuesday, 26. October
> Markus,
>    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 at geog.uni-hannover.de with
subject 'unsubscribe grass5'
length: 3949
max: 0

More information about the grass-dev mailing list