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 <[EMAIL PROTECTED]> _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
