[GRASS-dev] Some native Windows changes committed

[Paul Kelly]

I've committed quite a few MINGW-related changes to CVS there now. I hope 
that in the long run they will make it easier to make further changes to 
port GRASS to native Windows, although in the meantime I'm slightly 
worried they might upset the way GRASS can be cross-compiled for Windows 
from Linux; that needs to be tested and I can't do that. More detail on 
the changes below.

Configure script and Makefiles
==============================

Make an effort to separate the use of variables GISBASE and ARCH_DISTDIR. 
GISBASE is the location of the temporary location and used when creating 
manpages - this path needs to be in a form understood by the native 
operating system (i.e. c:/grass/grassdata format is OK) for opening files 
etc. ARCH_DISTDIR is where things are installed during the build process 
and should be in Msys format (i.e. /c/grass/grassdata-style). GISBASE and 
ARCH_DISTDIR are used interchangeably in Makefiles and unfortunately 
GISBASE was used far too widely to make it feasible to change it so there 
is a new variable called RUN_GISBASE which is used when needed for the 
fake/demo location.

Originally I had it that the configure script tested if the pwd command 
accepts a -W option (for Windows-style pathnames) and if so used that to 
populate RUN_GISBASE. The Msys-style pathname goes into ARCH_DISTDIR and 
is used for everything else. But some pwds seem to return true even when 
used with a non-existent flag so I've changed that to a simple test for 
MINGW32.

Apart from that removed all explicit MinGW conditional stuff from 
Makefiles and configure script (I think). It means the shared library 
status and stuff is detected and configured for MINGW the same as for 
other systems now. MinGW conditionals were a bit mixed up with 
Cross-compiling conditionals but should be OK now. Wasn't too sure about 
the GDAL cross-compiling test - couldn't see what it did so have left it 
out for now. This might affect the stuff Radim does with the Windows 
GRASS/QGIS combination? I will try to fix it if anyone has any problems as 
a result of the changes.

Also removed the fmode.o stuff that was linked against all the Windows 
binaries. Saw some discussion about this on the list - binary mode? but 
everything is working fine for me without it so have left it out. If it 
needs to go back in it should go in some of the variables in the MinGW 
section in aclocal.m4 I think.

One thing that I'm really not too sure about is the code that creates a 
copy of the GRASS shared libraries with the GRASS version number (6.3.cvs) 
as part of the filename and then creates symlinks to those without the 
version number in the filename.
I'm not sure why it does this. It was disabled for Mingw but I re-enabled 
it for consistency. Maybe it leads to two copies of the libraries now if 
the Windows filesystem doesn't support symlinks. But can anybody say what 
it is really needed for?

Display lib and PNGdriver fixes
===============================

As discussed on the mailing list:
http://grass.itc.it/pipermail/grass-dev/2006-October/026963.html

Directory separator charcter stuff
==================================

New macros added to gis.h:
GRASS_DIRSEP and HOST_DIRSEP

The idea being that internal to GRASS, as much as possible we use 
GRASS_DIRSEP (which is /). HOST_DIRSEP and GRASS_DIRSEP are used by the 
following new functions:

/* paths.c */
int G_is_dirsep(char);
char *G_convert_dirseps_to_host(char *);
char *G_convert_dirseps_from_host(char *);

I've used G_convert_dirseps_to_host() in a few places already. Mostly when 
passing pathnames to the system() function.

In that file there is also
int G_mkdir(const char *);

and also I've changed G_clear_screen() so that it uses cls instead of 
clear on Windows.

In lib/gis/env.c I've removed all the MINGW stuff as discussed on the 
list.

datum and ellipsoid reading functions fixed to handle DOS line endings in 
text files and handle GRASS_PAGER environment variable in a cross-platform 
way.
g.parser changed to handle scripts with DOS line endings. {G_strip() --> 
G_chop()}

Started to abandon the use of G_system() because it hardcodes the use of 
/bin/sh. The way it stops Ctrl-C interrupts being passed to the parent 
calling program is useful in some situations but I'm not sure how to make 
it work on Windows.

Chane Init.sh to set GRASS_PAGER to "more" on Windows if other options 
fail - it should always be there.

Change to G_gets() to handle the carriage return-line feed sequence found 
on Windows. I hope this change is OK:

        eof = fgets(p,100,stdin);
        /* strip the EOL character      */
-      p[strlen(p)-1]='\0';
+      if( strlen(p) > 1 && p[strlen(p)-1] == '\n' && p[strlen(p)-2] == '\r' )
+           p[strlen(p)-2]='\0'; /* Handles DOS/Windows "\r\n" */
+      else
+           p[strlen(p)-1]='\0'; /* Handles Unix "\n" or old Mac "\r" */
        /*      buf could be any length.  Any overflow will occur here. */
        strcpy(buf,p);

In many places in modules we have to change calls to G_getl() to G_getl2() 
to enable them to handle Windows newline sequences - I wonder why G_getl() 
was not just changed in CVS and then it would fix everything? Changing 
G_gets() like this to catch everything seems to me like definitely the 
easiest solution.

lib/init and g.setproj
======================

lib/init/mke_loc.c, set_data.c, g.setproj: fixes to system() calls etc. to 
make interactive location set-up work. Replace system("clear") call in 
Vasklib V_init() function with G_clear_screen(). Fixes problem discussed 
on list here:
http://grass.itc.it/pipermail/grass5/2006-October/026824.html

r.out.png
=========

Updates to add a .png extension to the output file if it isn't there.

r.average
=========

Fix so calling other modules with system() will work on Windows