[GRASS5] Jan's copyright notice ++

Markus Neteler neteler at geog.uni-hannover.de
Thu Nov 2 13:59:44 EST 2000


On Thu, Nov 02, 2000 at 01:19:02PM -0500, Frank Warmerdam wrote:
> Andreas Lange wrote:
> > 
> > Hi Frank,
> > 
> > i think you misunderstood me partly.
> > I was not thinking of auto-extractable function descriptions (like with
> > lclint) but only of a very simple tag for authors and copyright
> > statements. I think your proposal is very reasonable, but if we want
> > later to generate xml-desriptions for the info on the module (authors,
> > title, purpose of module) we have to re-write the same info again.
> > 
> > If we could agree on some simple concept we can avoid doubling the work.
> > No one will be forced to use this, esp. with the libraries the
> > information is not needed. This affects only the modules, where
> > currently the information is spread among source code, text files, old,
> > no longer maintained man-pages, html-files, READMEs, TODOs, howtos etc.
> > I believe that we can in the long run save much time if we agree on a
> > new, simple concept.
> > 
> > So i would propose to use the header you suggested for all library
> > files, but discuss how we can in future improve the modules concept
> > (again, we are not forced to implement this in every module, but if
> > someone reworks the code, it will be not too much work to implement
> > this).
> 
> Andreas, 
> 
> I would agree that we shouldn't spend much time putting in purposes for
> GRASS commands, since that is already addressed in the user help (in the
> .html file).  The duplication of author is likely not a big deal.
> 
> >> Beyond the above I would like to see capture of log messages automatically.
> >> I find it enormously useful to be able to scan back through log messages (the
> >> same messages entered on a CVS commit) when looking at source file. 
> 
> Markus says:
> >The problem might be that the files get longer and longer. Is there an
> >option to restrict the lines (aka versions) to be shown?
> 
> Markus, 
> 
> There is no way of instructing CVS to restrict the number of versions 
> inserted that i know of.  Normally I just hand trim the history when I
> see it getting very long.  I would also suggest omitting the $Log$
> from files like gisdefs.h that are likely to be updated very frequently
> with additions of prototypes and so forth.
I agree. And you are right, of course this list could be shortened manually
(even not a big deal).
 
> Shall we say the proposed header for library source files will be as shown
> below?  For grass commands the purpose might be as simple as "Mainline for
> r.in.gdal" with the user documentation existing elsewhere.  If a command
> is split into several files, the purpose should try to address what part of
> the overall work is done in that source file.
> 
> /***************************************************************************
>  * $Id: make_loc.c,v 1.2 2000/11/02 18:05:04 frankw Exp $
>  *
>  * MODULE: 	libgrass (should go into libgis)
>  * AUTHOR(S):	Frank Warmerdam - warmerda at home.com
>  * PURPOSE: 	Function to create a new location automatically given a 
>  *              "Cell_head", PROJ_INFO and PROJ_UNITS information.
>  * 
>  * COPYRIGHT:  	(C) 2000 by the GRASS Development Team
>  *
>  *   	    	This program is free software under the GPL (>=v2)
>  *   	    	Read the file COPYING that comes with GRASS for details.
>  *****************************************************************************
>  * $Log: make_loc.c,v $
>  * Revision 1.2  2000/11/02 18:05:04  frankw
>  * added G_set_cellhd_from_projinfo
>  *
>  * Revision 1.1  2000/10/31 04:39:43  frankw
>  * New
>  */
> 
> If this is acceptable I will update the SUBMITTING file accordingly.
>From my side it's nice. I am sure, Justin will like it, too. He is
online tomorrow (time shift: 5h from here or so).

Regards

 Markus

---------------------------------------- 
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo at geog.uni-hannover.de with
subject 'unsubscribe grass5'



More information about the grass-dev mailing list