osgeo4w patch update

[jef]

OSGeo4W's GRASS 6.4.1 will be build with the attached patch applied:

Patch:  http://buten.norbit.de/~jef/osgeo4w-grass64.diff

See also:  http://lists.osgeo.org/pipermail/osgeo4w-dev/2011-January/001192.html

[neteler]

patch from Jef

[hellik]

Patch for compiling with gdal18 and geos

[hellik]

I've tried to strip out from Jürgen's patch following:

- adapt to cleaned osgeo4w - with osgeo4w-gdal18 - with osgeo4w-geos

what I've not included:

- changes for packaging in the osgeo4w-setup - changes in locale/Makefile - changes in lib/db/dbmi_base - changes in lib/proj - changes in lib/g3d/ - changes in lib/gis/ - changes in gem/ - changes include/Make/Rules.make - changes in gui/wxpython/scripts/ - changes in configure.in - changes in general/g.region/

best regards Helmut

please review

[hellik]

Patch for lib/proj/

[hellik]

now there are extracted changes lib/proj/

please review

Helmut

[hellik]

general/g.region/printwindow.c

[hellik]

extracted changes for general/g.region/printwindow.c

please review.

Helmut

[hamish]

mswindows/osgeo4w/package.sh:

-#!/c/OSGeo4W/apps/msys/bin/sh 
+#!/c/Programme/OSGeo4W/apps/msys/bin/sh 

not portable dirname.

+export OSGEO4W_ROOT_MSYS=/c/Programme/OSGeo4W

local dirname, bashism with #!/bin/sh (but fwiw works in dash)

---

was all the change to use G_free(), db_free() needed or just "while you were there"? (needless clutter is to be avoided)

---

why was it necessary to disable the GIS_H_VERSION check in lib/gis/gisinit.c? it is there for your protection.

---

mostly I'm insterested to know if there are bugfixes in there we should know about, what is needed for a osgeo4w compile, what are cosmetic changes, and what in there is local preference/ personal setup.

thanks, Hamish

[hellik]

Hi Hamish

Replying to hamish:

mostly I'm insterested to know if there are bugfixes in there we should know about, >what is needed for a osgeo4w compile, what are cosmetic changes, and what in there is >local preference/ personal setup.

I've tried to extract only these things that seems to be necessary to compile in osgeo4w.

see also  http://lists.osgeo.org/pipermail/grass-dev/2011-February/053420.html

Hi Helmut,

On Sat, 12. Feb 2011 at 00:22:51 +0100, Helmut Kudrnovsky wrote:
> "
> [...]
> checking for location of zlib includes... 
> checking for zlib.h... yes
> checking for location of zlib library... 
> checking for deflate in -lz... no
> configure: error: *** Unable to locate zlib library."

The MinGW cruft was removed from osgeo4w (maybe still not complete, but
anyway).  I updated my package.sh accordingly (see ticket #1271).

For starters the mingw-libs package with the library copies (foo.lib =>
libfoo.a) are gone and package.sh now copies them before running configure.
That's probably what hits you here.

Jürgen

some comments:

- grass64svn_osgeo4w_gdal18_geos.patch: gdal-config and geos-config seem not be delivered anymore by osgeo4w, so therefore included in the grass-svn

- there are compiling errors in lib/proj, therefore grass64svn_osgeo4w_libproj.patch

- it seems that osgeo4w doesn't include projects.h, therefore grass64svn_osgeo4w_gregion.patch. but maybe this should be an osgeo4w-issue?

best regards Helmut

[hamish]

Replying to hellik:

some comments: - grass64svn_osgeo4w_gdal18_geos.patch: gdal-config and geos-config seem not be delivered anymore by osgeo4w, so therefore included in the grass-svn

that seems like bad practice. we can't hope to maintain/keep it in sync with upstream.

- it seems that osgeo4w doesn't include projects.h, therefore grass64svn_osgeo4w_gregion.patch. but maybe this should be an osgeo4w-issue?

code comments indicate projects.h is not public? the "libproj-dev" project on my linux system ships it (which is of course infallible truth :), so I'm not sure if that is correct or not.

• uneeded cloning of code is evil and a maintenance nightmare.

Hamish

[jef]

Hamish,

valid points. But I just filed this because Markus Neteler asked me to. Take what you like - or don't.

This is simply going to be how I will build GRASS 6.4.1 for OSGeo4W - unless somebody else steps up - but there doesn't seem to be much interest in contributing to OSGeo4W from the GRASS community.

As said before: I just maintain GRASS in OSGeo4W for the QGIS plugin - which I don't even use. Without it using OSGeo4W for the prebuilt dependencies, would probably have been the timesaver, I originally hoped it would be.

The (maybe unfortunate) truth is, that MSVC is the preferred compiler on Windows and so virtually everything is built with MSVC in OSGeo4W. It is only GRASS that is build with MinGW, because there isn't a way to build it with MSVC. It's tied to configure & make - instead of something more "portable" like cmake.

So in our case it's wrong to assume that there is a "system" gdal-config/geos-config. There isn't - upstream doesn't maintain a shell script that produces MinGW options in the VC build - and gdal-config/geos-config isn't useful for VC in any way.

Also most package produce windows libraries ie. foo.lib instead of libfoo.a, which configure doesn't look for - although MinGW could use them just fine.

So either switch to something like cmake, fix configure to support non-mingw stuff better or simply fake shell scripts that produce mingw options for vc built libraries and do copies of windows libraries.

Some more comments:

• package.sh is meant for msys' sh - and only msys' sh. Is there even a dash for windows?
• For projects.h, see [ http://trac.osgeo.org/osgeo4w/ticket/34] (but that's just FrankW talking :))
• The db_free stuff is just the usual let the DLL that malloced memory also free it. There are a couple of other tickets about the same issue with other DLLs (which I'm not going to lookup now),
• the gisinit stuff is just to avoid unnecessary rebuilds on my end,
• And guess why I removed the mingw cruft (which were projects.h, renamed .lib copies and made-up gdal-config/geos-config)? Right, maintanance nightmares ;)

[jef]

And BTW I contributed mswindows/osgeo4w for building for OSGeo4W - not just for building with OSGeo4W. You can use it as "stack" as you like to call it, but it could also be used for distribution. package.sh is meant to create packages for osgeo4w - although that very thing was commented out in the version in the GRASS repository. So I have to keep my own copy...

[martinl]

Most of suggested changes has been applied. Downgrading the priority. Any objection to close the ticket?

[hellik]

Replying to martinl:

Any objection to close the ticket?

grass64svn and grass65 are compiling without any problem here on my side.

compiling grass_trunk ends in my osgeo4w-build-environment in an endless loop of sh.exe and make.exe and crashes, I'll be able to test again this at the weekend.

beside this grass_trunk-issue, I would vote to close the ticket.

thanks a lot for applying the patches.

Helmut

[hellik]

Replying to hellik:

Replying to martinl:

Any objection to close the ticket?

grass64svn and grass65 are compiling without any problem here on my side. compiling grass_trunk ends in my osgeo4w-build-environment in an endless loop of sh.exe and make.exe and crashes, I'll be able to test again this at the weekend. beside this grass_trunk-issue, I would vote to close the ticket.

I don't know if ticket #1289 ( http://trac.osgeo.org/grass/ticket/1289) is possibly related to this issue (it's an issue in self compiled wingrass65 and in the wingrass65-nightly builds)?

and in the installer of the nightly-built wingrass7 there is an empty C:\Program Files\GRASS 7.0.SVN\grass70.py (tested with WinGRASS-7.0.SVN-r45532-1-Setup.exe).

Helmut

[hamish]

if the patch was not backed out and the relevant parts of it reapplied manually, I will be a PITA and ask to do a full audit of it before closing the ticket, as last time I checked it had a bunch of stuff that shouldn't have been checked into the main tree, or was checked in without adequate code comments justifying workarounds instead of fixes for the underlying problems. I would like to check that is no longer the case before closing the ticket. I think it's probably 95% ok, it's just that last 5% I'm worried about.

or was that already done and I missed it?

jef:

package.sh is meant for msys' sh - and only msys' sh. Is there even a dash for windows?

last time I checked msys uses bash as /bin/sh. what's odd about msys's version? (C:\ to /c/ stuff?)

also, what's the problem with g.parser's man page building?

thanks, Hamish

[hellik]

Replying to hellik: [...]

and in the installer of the nightly-built wingrass7 there is an empty C:\Program Files\GRASS 7.0.SVN\grass70.py (tested with WinGRASS-7.0.SVN-r45532-1-Setup.exe).

grass70.py is now installed in C:\OSGeo4W\bin

from dev-ML  http://lists.osgeo.org/pipermail/grass-dev/2011-March/053570.html

The original osgeo4w package puts these files into `c:\osgeo4w\bin`
(btw including some extra tmpl files, which is not needed). I can't
see any good point why to create some extra directory which is
moreover not included in the path by default. So I would suggest to
forget about `c:\osgeo4w\apps\grass\bin`.

but GRASS-packager.bat of grass70 is looking for grass70.py in c:\osgeo4w\apps\grass\bin

[...]
set GRASS_BIN_PREFIX=%OSGEO4W_DIR%\apps\grass\bin
[...]
xcopy %GRASS_BIN_PREFIX%\grass70* %PACKAGE_DIR% /S/V/F

Helmut

[hellik]

Replying to hellik:

from dev-ML  http://lists.osgeo.org/pipermail/grass-dev/2011-March/053570.html

The original osgeo4w package puts these files into `c:\osgeo4w\bin`
(btw including some extra tmpl files, which is not needed). I can't
see any good point why to create some extra directory which is
moreover not included in the path by default. So I would suggest to
forget about `c:\osgeo4w\apps\grass\bin`.

I first compiled grass64svn and grass64.bat is written to c:\osgeo4w\bin, which points to following:

@echo off
call C:\OSGeo4W\bin\o4w_env.bat
"%WINGISBASE%"\etc\init.bat %*

but after compiling grass65, grass65.bat is also written to c:\osgeo4w\bin, which points also to following:

@echo off
call C:\OSGeo4W\bin\o4w_env.bat
"%WINGISBASE%"\etc\init.bat %*

and the content of o4w_env.bat points to grass65 now

set GISBASE=%OSGEO4W_ROOT%\apps\grass\grass-6.5.svn 
set WINGISBASE=%OSGEO4W_ROOT%\apps\grass\grass-6.5.svn 
set GRASS_SH=%OSGEO4W_ROOT%\apps\msys\bin\sh.exe
set GRASS_WISH=%OSGEO4W_ROOT%\bin\wish.exe
set GRASS_PYTHON=%OSGEO4W_ROOT%\bin\python.exe
set GRASS_PROJSHARE=%OSGEO4W_ROOT%\share\proj
set GRASS_HTML_BROWSER=%PROGRAMFILES%\Internet Explorer\iexplore.exe
set PATH=%OSGEO4W_ROOT%\apps\grass\grass-6.5.svn\bin;%PATH%

so grass64 and grass65 can't coexist at the moment in the osgeo4w-stack.

Helmut

btw

GRASS_HTML_BROWSER=%PROGRAMFILES%\Internet Explorer\iexplore.exe

should be set to

GRASS_HTML_BROWSER=explorer

that default internetbrowser of the system is invoked (the same as that the nsis-installer does).

[martinl]

Replying to hellik:

I first compiled grass64svn and grass64.bat is written to c:\osgeo4w\bin, which points to following: {{{ @echo off call C:\OSGeo4W\bin\o4w_env.bat "%WINGISBASE%"\etc\init.bat %* }}}

strange, one line is missing here

call C:\OSGeo4W\apps\grass\grass-6.5.svn\etc\env.bat

o4w_env.bat contains

@echo off
set OSGEO4W_ROOT=C:\OSGeo4W
PATH=%OSGEO4W_ROOT%\bin;%PATH%
for %%f in ("%OSGEO4W_ROOT%"\etc\ini\*.bat) do call "%%f"
@echo on

and C:\OSGeo4W\apps\grass\grass-6.5.svn\etc\env.bat grass-version related environments

set GISBASE=%OSGEO4W_ROOT%\apps\grass\grass-6.5.svn
set WINGISBASE=%OSGEO4W_ROOT%\apps\grass\grass-6.5.svn
set GRASS_SH=%OSGEO4W_ROOT%\apps\msys\bin\sh.exe
set GRASS_WISH=%OSGEO4W_ROOT%\bin\wish.exe
set GRASS_PYTHON=%OSGEO4W_ROOT%\bin\python.exe
set GRASS_PROJSHARE=%OSGEO4W_ROOT%\share\proj
set GRASS_HTML_BROWSER=%PROGRAMFILES%\Internet Explorer\iexplore.exe
set PATH=%OSGEO4W_ROOT%\apps\grass\grass-6.5.svn\bin;%PATH%

?

Martin

[martinl]

Replying to hellik:

> GRASS_HTML_BROWSER=%PROGRAMFILES%\Internet Explorer\iexplore.exe

should be set to

> GRASS_HTML_BROWSER=explorer

that default internetbrowser of the system is invoked (the same as that the nsis-installer does).

fixed in r45557

[hellik]

Replying to martinl:

?

ok, it was a hard week at work :o) ... I will do it again with a fresh svn-checkout of grass64svn and grass65 in the next days.

best regards Helmut

[hellik]

Replying to hellik:

Replying to hellik: [...]

and in the installer of the nightly-built wingrass7 there is an empty C:\Program Files\GRASS 7.0.SVN\grass70.py (tested with WinGRASS-7.0.SVN-r45532-1-Setup.exe).

grass70.py is now installed in C:\OSGeo4W\bin from dev-ML  http://lists.osgeo.org/pipermail/grass-dev/2011-March/053570.html {{{ The original osgeo4w package puts these files into c:\osgeo4w\bin (btw including some extra tmpl files, which is not needed). I can't see any good point why to create some extra directory which is moreover not included in the path by default. So I would suggest to forget about c:\osgeo4w\apps\grass\bin. }}} but GRASS-packager.bat of grass70 is looking for grass70.py in c:\osgeo4w\apps\grass\bin {{{ [...] set GRASS_BIN_PREFIX=%OSGEO4W_DIR%\apps\grass\bin [...] xcopy %GRASS_BIN_PREFIX%\grass70* %PACKAGE_DIR% /S/V/F }}}

fixed with r45560

Helmut

[martinl]

Replying to martinl:

> call C:\OSGeo4W\apps\grass\grass-6.5.svn\etc\env.bat

btw, in r45561 env.bat moved to c:\osgeo4w\etc\ini\grass65.bat

[jef]

Replying to martinl:

Replying to martinl: {{{

call C:\OSGeo4W\apps\grass\grass-6.5.svn\etc\env.bat

}}} btw, in r45561 env.bat moved to c:\osgeo4w\etc\ini\grass65.bat

That way multiple GRASS version can't coexist.

The files in etc/ini are general versions - which should only be used when there is only one version. These are sources from o4w_env.bat, which is used by several start files in bin.

For packages in multiple version there are batch files in bin (GDAL for example) that are either invoked manually from the shell to activate a specific version (like gdal17.bat) or implictely from the start batch file of the other software (e.g. grass.bat currently uses gdal17.bat and qgis-dev.bat uses grass-env.bat).

The patch puts init.bat.tmpl into bin/grass$POSTFIX-env.bat.tmpl, which is updated with the actual install path on install by etc/postinstall/grass$POSTFIX.bat (from postinstall.bat) and sourced from grass$POSTFIX.bat (from grass.bat.tmpl) which then invokes the actual init.bat in apps/grass-$POSTFIX/etc/init.bat.

[martinl]

Replying to jef:

btw, in r45561 env.bat moved to c:\osgeo4w\etc\ini\grass65.bat

That way multiple GRASS version can't coexist. The files in etc/ini are general versions - which should only be used when there is only one version. These are sources from o4w_env.bat, which is used by several start files in bin. For packages in multiple version there are batch files in bin (GDAL for example) that are either invoked manually from the shell to activate a specific version (like gdal17.bat) or implictely from the start batch file of the other software (e.g. grass.bat currently uses gdal17.bat and qgis-dev.bat uses grass-env.bat).

right, revered in r45564.

The patch puts init.bat.tmpl into bin/grass$POSTFIX-env.bat.tmpl, which is updated with the actual install path on install by etc/postinstall/grass$POSTFIX.bat (from postinstall.bat) and sourced from grass$POSTFIX.bat (from grass.bat.tmpl) which then invokes the actual init.bat in apps/grass-$POSTFIX/etc/init.bat.

init.bat.tmpl has been renamed to env.bat.tmpl and it's currently installed into $GISBASE\etc\env.bat. There are only two files installed into c:\osgeo4w\bin

• grass$POSTFIX by make install (shell script)
• grass$POSTFIX.bat by package.sh (bat script)

[hellik]

Replying to hellik:

Replying to martinl:

Any objection to close the ticket?

grass64svn and grass65 are compiling without any problem here on my side. [...] thanks a lot for applying the patches.

patches applied and a lot of fixes done in the last months.

closing ticket, reopen if needed.

Helmut