[GRASS-dev] Some native Windows changes committed

[Glynn Clements]

Paul Kelly wrote:

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

AFAICT, the version number doesn't have any real purpose.

The GRASS shared libraries aren't versioned in the sense that most
shared libraries are (i.e. with a trailing version number,
incorporated in the library's soname).

The main reason being that there isn't any point unless you increment
the version number whenever the ABI changes, and the GRASS development
process isn't really disciplined enough to do that.

> Started to abandon the use of G_system() because it hardcodes the use of 
> /bin/sh.

G_system() specifically uses command.com on Windows:

	#ifdef __MINGW32__
	    signal (SIGINT,  SIG_DFL);
	    _spawnl ( P_WAIT,
	              "command",
	              "command",
	              "/c",
	              command,
	              NULL );
	#else    

If anything, we should move towards G_system() rather than away from
it. That would allow various portability hacks to be localised in one
place rather than spread across modules.

Better still would be to implement G_spawn[_ex] on Windows and use
that instead. Those functions don't use a shell, which eliminates a
major source of potential problems.

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

Note that system() behaves in the same way; at least, it's supposed
to. The comments for that function suggest that it was implemented as
a workaround for platforms with broken system() functions.

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

Probably because someone thought that there *might* be a situation
where the CR needed to be preserved, and didn't want to scan the
entire source tree to check.

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

The vask library should just use the curses clear() function. The
"problem" with it not "working" on xterm isn't a problem, but a
feature.

Using system("clear") etc is a hack for programs which want to clear
the screen (and many of these probably *shouldn't* be clearing the
screen) but where using curses would be overkill.

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