[GRASS-dev] WinGRASS Wiki Hacking

[Glynn Clements]

Markus Neteler wrote:

> > Ah, I mistook this email exchange to be an interest in actually packaging
> > wingrass for OSGeo4W.  I see it is not.
> 
> I would not see it so negatively.
> There is definitely the interest in packaging winGRASS for OSGeo4W.
> The technical issues need to be worked out, this will likely take more time
> than the duration of this thread (only 5 days now).
> 
> > I'll return to my corner and wait patiently in the hopes someone shows more
> > interest participating in OSGeo4W.
> 
> To my knowledge (off list private communication) there are some folks
> interested to participate in OSGeo4W. Only the entry "barrier" seems to
> be too high from what I understood - at least there is some communication
> issue. I feel that this could be rather easily resolved, at least I hope so.
> Since we have limited resources, we should share code as much
> as possible.
> It is clear that we need winGRASS as standalone package (we are
> already there), but it is also of high interest to integrate it into OSGeo4W
> (we are not yet there).
> 
> @All involved: What about putting frustrations aside and start again?

FWIW, my frustrations are mainly with Windows, not with anything which
Frank has said.

Unfortunately, there are conflicting imperatives. E.g.: making GDAL
use stdcall increases compatibility with various parts of the Windows
"ecosystem" (e.g. VB, Delphi) at the expense of decreasing
compatibility with Unix-oriented software (specifically, with
autoconf).

There's also the inevitable conflict between a preference for MSVC
amongst many Windows developers, and the preference for MinGW both for
Unix-compatibility and because it is free (speech *and* beer).

The stdcall issue could be fixed by avoiding AC_CHECK_FUNC in favour
of an explicit test program. We already do this for the OpenGL checks,
as the OpenGL libraries also use stdcall.

However, I'm reluctant to rely unnecessarily upon having
platform-specific cases, given the minority status of Windows amongst
GRASS users and (especially) developers, as there's always a risk that
the Windows specific parts won't get updated and/or tested regularly
enough.

There's also the issue that GRASS and GDAL share some DLLs (e.g. 
zlib), and some of those DLLs have Windows-specific quirks (e.g. -lz
doesn't work with the standard Windows binaries for zlib). So, if we
use the existing GDAL binaries, we would probably have to adjust the
zlib tests as well. Having GRASS use the GnuWin32 zlib while GDAL uses
the version from zlib.net would probably cause problems.

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