[GRASS5] Comment on source code structure

[Markus Neteler]

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 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