[GRASS5] cvs updates completed successfully.

Michael Barton michael.barton at asu.edu
Sun Sep 19 13:10:59 EDT 2004

Thanks both for explaining this and for finishing this last important


On 9/18/04 7:23 PM, "Hamish" <hamish_nospam at yahoo.com> wrote:

>>> I'm referring to scripts/Makefile, not scripts/r.univar.sh/Makefile.
>> I was too. That's what's strange. I did look yesterday morning. In
>> fact Hamish updated this Makefile a few days ago to have r.univar.sh.
>> So I am baffled as to why it is now showing r.univar (with Hamish
>> still listed as updating it).
> Ok, we have:
> grass51/scripts/r.univar/    (now empty)
> grass51/scripts/r.univar.sh/ (now populated)
> grass51/scripts/Makefile     (which script directories to look into)
> the Makefile [generally] works on stuff at the same directory level.
> i.e. the names listed in "grass51/scripts/Makefile" refer to the
> directories that 'make' should descend into, where it will look for new
> Makefiles. It does not have anything to do with the final name of the
> module besides being convenient. Thus a generic name (like r.univar/) was
> fine for the directory name as it gets the idea across with the minimum
> unnecessary yet unambiguous information. ie it didn't really matter as long
> as the directory structure and scritps/Makefile agreed.
> The final name for the module is defined in the Makefile that is in the
> source code directory (grass51/scripts/r.univar.sh/Makefile; "PGM = x.foo").
> For scripts "make"ing just means copying to $GISBASE/scripts/, so the script
> name does have to be correct there. For C code, all you have to do is rename
> PGM in the module/Makefile file to rename the module.
> The problem with renaming & moving directories in CVS is that you lose
> the modification history. It still exists in the Attic/ (why you shouldn't
> delete old directories) but is rather confusing to follow the history that
> way. Thus it is better to try and avoid renaming files and the directory
> structures if at all possible. Limitation of CVS, but somewhat logical I
> guess from the perspective of keeping the change history intact.
>>>> The reason for renaming it is that there is a binary module also
>>>> named r.univar. According to Markus, r.univar (binary) will
>>>> eventually have all the functionality (and more?) of r.univar.sh
>>>> (script). However, it is still under development so we are keeping
>>>> the script for awhile.
>>> I was asking why you renamed the directory; I know why you renamed
>>> the script.
>> I renamed the directory because I thought it ought to match the
>> script.
> as above, that isn't required and should be avoided unless there is a
> compelling reason.
>> If it is better to do it another way, please do so.
> I've just modified grass51/scripts/Makefile to reflect the new directory
> name. Everything should be working now, no further changes required.
> Hamish

C. Michael Barton, Professor
School of Human Diversity and Social Change
PO Box 872402
Arizona State University
Tempe, AZ  85287-2402

Phone: 480-965-6262
Fax: 480-965-7671
www: <www.public.asu.edu/~cmbarton>

More information about the grass-dev mailing list