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