[GRASS-dev] GRASS and QGIS on Win32, testing etc.

[Glynn Clements]

Benjamin Ducke wrote:

> My problem simply is that I am getting tangled up in the different Win32
> migration schemes used by the GRASS and QGIS developers. I would love to
> provide Win32 testing feedback and reports for compilation, installation
> and usage, but I simply don't know where to start!
> 
> Could we please decide on one common approach to supply a stable GRASS
> Win32 base that can be shared by both the GRASS and QGIS teams? As far
> as I understand, Moritz' system differs in that it supports the Tcl/Tk
> stuff? But now there is talk about getting rid of MSYS?
> 
> Sorry for the lengthy post and all the complaining but if you could
> stand inside my shoes right now, you would see a great chance to claim a
> good share of an entire discipline for GRASS GIS. And not being able to
> make use of this is pretty frustrating.

1. The intent is to support both Cygwin and (native) Windows. Even if
the native version had the same level of functionality as the Cygwin
version, some people will want to use it under Cygwin for other
reasons.

2. With the native version, the intent is that MSys shouldn't be
required to use GRASS, only to build it.

But so long as GRASS includes Bourne-shell scripts, you will need a
compatible shell in order to use those scripts, and MSys is the most
readily available.

Beyond that, if you prefer bash to cmd.exe, then Init.sh will try to
support using it as the session shell. However, MSys' version of bash
uses a virtual Unix-like filesystem which isn't compatible with the
rest of Windows. Also, Windows pathnames aren't compatible with
certain Unix conventions, most notably the fact that search paths
($PATH etc) use a colon as a separator.

Ultimately, getting a "genuinely" native Windows version working takes
precedence. And that means that valid Windows pathnames (e.g. 
"C:\path\to\file") need to work everywhere. If that causes problems
for MSys, that's MSys' problem (in the sense that workarounds will
only be accepted if they don't break native usage).

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