[GRASS-dev] winGRASS native

[Glynn Clements]

Hamish wrote:

> > > > I used the GRASS version from:
> > > > http://geni.ath.cx/grass.html#toc2
> > > > It says: 6.3.CVS September 17, 2006
> > > >
> > > > Unfortunately i have not recorded the errors... But if i remember
> > > > well
> ..
> > > > 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.
> 
> 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)

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.

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

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

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

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?

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