[GRASS-dev] winGRASS native

[Glynn Clements]

Hamish wrote:

> > > > > > Things that could not work on GRASS GIS native:
> > > > > > - r.watershed (Neither GUI nor CLI worked)
> > > ..
> > > > > > About r.watershed, it mentioned something about /RAM that was
> > > > > > making the problem. sorry for this poor info, i dont have
> > > > > > Windows box around.
> HB:
> > > IIUC, r.watershed/seg/Makefile and r.watershed/ram/Makefile need to
> > > have $(EXE) added to the end of the support binaries so they'll get
> > > .exe extensions. (I'm not sure where/how in the Makefile to do this)
> GC:
> > There are two possible approaches:
> > 
> > 1. Add $(EXE) to the definition of PGM= in the Makefile.
> > 
> > 2. Add $(EXE) to the "etc" rules in Module.make, and add it to the
> > $(INSTALL) command in the Makefile.
> 
> 
> compare:
>   raster/r.support/modhead/Makefile 

Uses #1.

> and
>   raster/r.watershed/ram/Makefile

Uses neither, and so fails.

> r.support/modhead:
> ---
> MODULE_TOPDIR = ../../..
> 
> PGM = modhead$(EXE)
> 
> LIBES = $(EDITLIB) $(VASKLIB) $(GISLIB) $(CURSES)
> DEPENDENCIES = $(GISDEP) $(EDITDEP) $(VASKDEP)
> 
> include $(MODULE_TOPDIR)/include/Make/Module.make
> 
> default: etc
>         $(MKDIR) $(ETC)/support
>         mv $(ETC)/$(PGM) $(ETC)/support
> 
> htmletc1:
>         @echo "No docs to generate."
> ---
> 
> 
> r.watershed/ram:
> ---
> MODULE_TOPDIR = ../../..
> 
> PGM = r.watershed.ram
> 
> LIBES = $(GISLIB)
> DEPENDENCIES = $(GISDEP)
> 
> include $(MODULE_TOPDIR)/include/Make/Module.make
> 
> default: etc 
>         $(MKDIR) $(ETC)/water
>         $(INSTALL) -m 755 $(ETC)/$(PGM) $(ETC)/water
> 
> htmletc1:
>         @echo "No docs to generate." 
> ---
> 
> 
> * in r.support $(EXE) gets added to $(PGM) so no need for it to be used
> with each $(INSTALL) as well.

Adding it to PGM may cause problems with HTML files. It's probably
better to consider the .exe suffix as not being part of the program
name.

Makefiles which need to know the executable's exact filename should
probably use $(PROG) (but we need something similar for "etc"
programs).

Ultimately, I suspect that using subdirectories of $(ETC) will cause
more problems than it's worth.

> * r.support uses "mv" while r.watershed uses $(INSTALL). This explains
> why there end up being two copies of seg and ram in etc/ and etc/water/.
> (cp vs mv). The solution eludes me.
> 
> * after renaming "ram" and "seg" to "r.watershed.{ram|seg}" it complains
> that those module are missing man pages when rebuilding grass. does it
> have anything to do with raster/r.watershed/Makefile missing this line:
>   include $(MODULE_TOPDIR)/include/Make/Dir.make
> ?

In my copy, the Makefile includes that line.

I'm not sure whether you've made any changes, but Html.make uses
$(PGM) in the rules. If you add $(EXE) to the definition of PGM, the
.exe will end up in the name of the .html file, which might cause
problems.

> > > Any more thoughts on a hierarchy for the $GISBASE/etc/ dir?
> > > To help with multi-platform packaging it would be nice to segregate
> > > scripts and tcl from binaries, but as far as GRASS is concerned a
> > > support program is a support program regardless of what language was
> > > used to write it. 
> > 
> > I suggest treating scripts the same as binary executables, even though
> > that means having multiple copies on multi-architecture filesystems. 
> 
> I agree for shell scripts, but what about big tcl files? (etc/ gis.m,
> d.m, nviz,..) and in future large amounts of python code..

Don't worry about it. If there are significant directory trees which
take up a significant amount of space, the administrator can always
replace copies with symlinks.

To be honest, I suspect that the number of multi-architecture GRASS
installations could be counted on the fingers of one hand (and quite
possibly even on the thumbs of one hand ;) ).

-- 
Glynn Clements <glynn at gclements.plus.com>