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

[Moritz Lennert]

On 21/05/07 13:58, Benjamin Ducke wrote:
> Hi all,
> 

[...]

> I can tell you that interest in GRASS (and QGIS) is enormous among
> archaeologists, but it will not be possible to establish GRASS unless
> there is a version that installs and runs well on Win32.
> 
> Now, I have been following the diverse attempts to migrate GRASS to
> Win32 -- CygWin, cross compiling, MSYS, etc. -- but I am finally getting
> totally confused about where things are heading.
> 
> So far, I get the most usable system using the MSYS building environment
> provided by the QGIS developers.

How is this more usable then our native builds ? Or are you speaking 
about using GRASS from within QGIS ?

> 
> HOWEVER, there are two issues that have been sticking around for months
> now and prevent me from using the software productively in GIS classes:
> 
> 1. The DBF driver deadlocks randomly!
> Any GRASS module that needs to access the attribute table (DBF format)
> of a vector map is prone to this: E.g. I tried running v.out.ogr on a
> map with ca. 3000 points repeatedly. Out of ten runs, 2 or 3 deadlock at
> a random point. The task manager shows that v.out.ogr is sleeping with
> 0% CPU.
> Sometimes, I also get random "DBMI protocol errors". The only thing that
> helps is to stop and restart the module, hoping that it will finish this
> time. Quite annoying. I tested this with several different versions of
> QGIS, Windows (XP, 2000) and with different datasets on different PCs:
> always the same problem.
> 
> Is this the same bug that was/is being discussed under "What is missing"
> here: http://grass.gdf-hannover.de/wiki/WinGRASS_Current_Status ???

No, this issue was solved by compiling xdr as static, instead of shared 
library. See followups on the same page.

> I have replaced the QGIS 0.8.1 rc1 GRASS binaries with Moritz' version,
> but the problem persists. If you want to verify this, here is the sample
> location I used:
> 
> ftp://ftp.rz.uni-kiel.de/pub/ufg/qgis-test.zip
> 
> ... very simple point data, projection free.

Will try as soon as I can.

> 
> 2. There are still issues when QGIS is installed in a path with spaces.
> This is a problem with the GRASS modules. I found that at least
> g.mremove and d.mon screwed up. There are probably others ...

d.mon ? Does that mean you get GRASS monitors working ?

g.mremove is a script which can cause all kinds of shell related problems.

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

 From a pure GRASS point of view, please test the native builds I post 
regularly.

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

I think that this might be good idea, but we have to make sure that we 
are aiming at the same things.

> As far
> as I understand, Moritz' system differs in that it supports the Tcl/Tk
> stuff? 

It supports Tcl/Tk. Don't know if that's the only difference.

> But now there is talk about getting rid of MSYS?

You have to differentiate between MinGW/Msys as build environment and 
Msys as the shell of choice.

At this stage, the idea is to try to aim for a win version of GRASS 
which is as generic as possible, not imposing the use of one specific 
shell (e.g. msys), or actually any shell at all.

This means replacing any shell commands used within C-code (e.g. 
system("ls")) with C-code. Work on this has begun, and Glynn has 
provided more tools, although some still need to be ported to Windows.

This also means that any shell scripts (e.g. g.mremove, v.dissolve, etc) 
will either have to be replaced by C-versions (which kind of defeats 
their purpose of being easily codable for a larger number), be coded in 
a cross-platform scripting language (e.g. Python), or anyone who wants 
to use these under Windows has to provide access to a series of shell 
tools (e.g. through 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.

I am in the same situation as you are (we will migrate all our courses 
to free software starting next academic year !), so let's try to solve 
this together as quickly as possible. :-)

Moritz