[GRASS-dev] GRASS 6.4.2RC1 planning

[Hamish]

Glynn wrote:
> > > Make itself doesn't have any quoting mechanism, so you
> > > can't have spaces in any path which is used as part of
> > > a target or prerequisite, or an "include" directive, or
> > > which is processed by make functions (patsubst, wildcard,
> > > etc).
Hamish:
> > as there will be spaces in both the C:\Program Files\ for the
> > grass include headers and C:\Documents and Settings\ for the
> > build ($MAPSET/.tmp/) + install target,
Glynn:
> The default is to put everything under C:\OSGeo4W. If you
> want to use e.g. C:\Program Files, you need to ensure that
> only 8.3 pathnames are used.

I'm hoping (perhaps in vain) to get this going for end-users
without the full development stack in place. I wonder how hard
it would be to write a small C or python program which could
convert the string to an 8.3 pathname, as %%~sFoo might do in a
batch file?  so we could build in something like:
if [ -n "$MSYS" ] ; then
    MAPSET_DIR_safe=`g.dosname path="$MAPSET_DIR"`
fi

Python os.lib 1-liner?

It may be that for WinGrass we end up just shipping an addons
collection installer with them all pre-built, but I think it is
worth a bit of effort to see how far we can get with g.extension.

for now I've added a warning to the script in devbr6 so that it
sends out a warning if it detects a space.


> Also, AFAICT the installer doesn't attempt to fix ${prefix}
> to match the actual installation directory, so if the user
> chooses a different location, Platform.make will be wrong.

right; not really sure how to do an 'sed -i' at install time
with the nsi installer tools.  fwiw in the last days I've done
that replacement in Debian's git packaging rules repo, for future
ubuntu and debian packages.

If we are going to use ${GRASS_ADDON_PATH[0]} as a sort of
GRASS_ADDON_BASE dir, I wonder if we should add each dir in the
$GRASS_ADDON_PATH + ./man/ + `manpath` in a $MANPATH as part of
init.sh? Not sure how to get the html pages automatically
registered into the system, although Martin's and/or William's
enhancements may already have solved that.


Hamish

ps- not ignoring g.extension.py, just not bothering to port over
all these little experiments until we've settled on the best
approach.