[GRASS-dev] GRASS 6.4.2RC1 planning

[Glynn Clements]

Hamish wrote:

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

	>>> win32api.GetShortPathName(r'c:\Program Files (x86)\Python27')
	'c:\\PROGRA~2\\Python27'

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

One option is to move the variables containing the paths (prefix,
GRASS_HOME, and RUN_GISBASE) to a separate file, e.g. Paths.make. 
Then, the installer could replace that file in its entirety, rather
than having to modify specific lines in Platform.make.

OTOH, most of those variables aren't particularly relevant for
building add-ons. E.g. If you're building against an installed GRASS,
RUN_GISBASE probably needs to point to the installed version, not the
source tree.

Actually, some of them might need to be split, in the same way that
7.0 has ARCH_LIBDIR and BASE_LIBDIR. ARCH_LIBDIR is where
freshly-compiled libraries should be stored, BASE_LIBDIR is where
existing GRASS libraries are found. For a normal build, both of these
point to dist.<arch>/lib; when building add-ons, ARCH_LIBDIR points at
the add-ons source tree, BASE_LIBDIR points at the installed GRASS.

RUN_GISBASE is used mainly to set PYTHONPATH (RUN_GISBASE uses Windows
syntax rather than MSys syntax). If you're building an add-on which
includes some Python modules and a script which imports both add-on
modules and stock grass.{script,lib} modules, PYTHONPATH will need to
include both sets of directories.

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