[GRASS-dev] winGRASS native

[Hamish]

> > > > > 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 
and
  raster/r.watershed/ram/Makefile


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.

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


> I prefer the latter option, as this is consistent with the way that
> "normal" programs are handled. Module.make automatically adds $(EXE)
> to $(PGM) for "cmd" and "inter" rules, but not for "etc". This means
> that the definition of PGM in the module's Makefile has to include
> $(EXE) for "etc" but mustn't include it for "cmd" or "inter".

I agree. Better to be consistent and control it from one place.

I leave it to someone else to implement as I don't use windows & can't
test.

> > 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..
 
> They don't take up much space, and we won't have to track down their
> callers if someone replaces a binary with an equivalent script (or
> vice-versa).

agree.

> Separating programs (whether binaries or scripts) from data files
> seems a reasonable goal. However, some binary data files may be
> platform dependent (byte order, sizeof(long) etc). Aren't some of the
> datum grids architecture-specific?

sounds vaugely familiar.


Hamish