wingrass - nsis - script in release mode: !define SVN_REVISION "@GRASS_VERSION_SVN@" not set

[hellik]

​http://trac.osgeo.org/grass/browser/grass/branches/releasebranch_6_4/mswindows/GRASS-Installer.nsi.tmpl#L19

19	;Select if you are building a "Development Version" (Devel) or a "Release Version" (Release) of the GRASS Installer
20	
21	!define INSTALLER_TYPE "Devel"

​http://trac.osgeo.org/grass/browser/grass/branches/releasebranch_6_4/mswindows/GRASS-Installer.nsi.tmpl#L31

31	;Version variables
32	
33	!define SVN_REVISION "@GRASS_VERSION_SVN@"

in release mode @GRASS_VERSION_SVN@ isn't set:

!define SVN_REVISION "" <=
!define BINARY_REVISION "1"
!define VERSION_NUMBER "6.4.3RC3"
!define GRASS_BASE "GRASS GIS 6.4.3RC3"
[...]

so ​http://trac.osgeo.org/grass/browser/grass/branches/releasebranch_6_4/mswindows/GRASS-Installer.nsi.tmpl#L251

251	        !define /math VERSION ${SVN_REVISION} + ${BINARY_REVISION}

doesn't work and nsis stopps with an error

[hellik]

Replying to hellik:

in release mode @GRASS_VERSION_SVN@ isn't set:

source get by a svn checkout

[martinl]

Replying to hellik:

​http://trac.osgeo.org/grass/browser/grass/branches/releasebranch_6_4/mswindows/GRASS-Installer.nsi.tmpl#L19

> 19	;Select if you are building a "Development Version" (Devel) or a "Release Version" (Release) of the GRASS Installer
> 20	
> 21	!define INSTALLER_TYPE "Devel"

The installer type should be not related to this ticket. At least I didn't encountered any problem when building osgeo4w package source:grass-addons/tools/wingrass-packager/grass_svn_info.sh#L34​

​http://trac.osgeo.org/grass/browser/grass/branches/releasebranch_6_4/mswindows/GRASS-Installer.nsi.tmpl#L31

> 31	;Version variables
> 32	
> 33	!define SVN_REVISION "@GRASS_VERSION_SVN@"

in release mode @GRASS_VERSION_SVN@ isn't set:

> !define SVN_REVISION "" <=
> !define BINARY_REVISION "1"
> !define VERSION_NUMBER "6.4.3RC3"
> !define GRASS_BASE "GRASS GIS 6.4.3RC3"
> [...]

replacement should be done automatically (source:grass/branches/releasebranch_6_4/mswindows/Makefile#L22​) when SVN rev number is defined in source:grass/branches/releasebranch_6_4/include/Make/Grass.make.in#L75​. Do you have svnversion in the path (when running configure)?

[martinl]

Replying to martinl:

replacement should be done automatically (source:grass/branches/releasebranch_6_4/mswindows/Makefile#L22​) when SVN rev number is defined in source:grass/branches/releasebranch_6_4/include/Make/Grass.make.in#L75​. Do you have svnversion in the path (when running configure)?

source code downloaded from SVN? If you use tarball, it will fail (missing svn number).

[hellik]

Replying to martinl:

Replying to martinl:

replacement should be done automatically (source:grass/branches/releasebranch_6_4/mswindows/Makefile#L22​) when SVN rev number is defined in source:grass/branches/releasebranch_6_4/include/Make/Grass.make.in#L75​. Do you have svnversion in the path (when running configure)?

source code downloaded from SVN? If you use tarball, it will fail (missing svn number).

see #1940#comment:1

source was from a svn check out

[hellik]

Replying to martinl:

Do you have svnversion in the path (when running configure)?

from the msys-cmdline

myricaria@MYRICARIA-HP ~
$ svnversion --version
svnversion, version 1.7.0 (r1176462)
   compiled Oct 10 2011, 22:03:27

[hamish]

Hi,

just to note in the release tarball there are no .svn/ dirs present, so svnversion (if installed) should just return "exported" to stdout.

I'm not sure what happens with 'svn export' of a branch, I assume the same, but hellik reports using 'svn checkout', which should have .svn/ dirs, so something else is going on.

If there are things which need to be changed just before release, then changed back just after, automatically-detecting is best but if that is not possible please document what needs to be done in src:doc/howto_release.txt.

fwiw, Hamish

[hellik]

Replying to hamish:

Hi,

just to note in the release tarball there are no .svn/ dirs present, so svnversion (if installed) should just return "exported" to stdout.

I'm not sure what happens with 'svn export' of a branch, I assume the same, but hellik reports using 'svn checkout', which should have .svn/ dirs, so something else is going on.

Author: neteler Date: 2013-04-20 08:29:47 -0700 (Sat, 20 Apr 2013) New Revision: 55934

myricaria@MYRICARIA-HP /osgeo4w/usr/src/grass643RC3
$ svnversion
55936

[martinl]

Replying to hellik:

Replying to martinl:

Do you have svnversion in the path (when running configure)?

When you launch configure or better package.sh you should get (see package.log)

checking for svnversion... /c/Subversion/svnversion

include/Make/Grass should contain

GRASS_VERSION_SVN     = XXXXXX

In other words, try to check if svnversion is in the path when running package.sh. (?)

[hellik]

Replying to martinl:

Replying to hellik:

Replying to martinl:

Do you have svnversion in the path (when running configure)?

When you launch configure or better package.sh you should get (see package.log)

checking for svnversion... /c/Subversion/svnversion

include/Make/Grass should contain

GRASS_VERSION_SVN     = XXXXXX

In other words, try to check if svnversion is in the path when running package.sh. (?)

from package log

checking for svnversion... no

from osgeo4w-msys from where I start package.sh

myricaria@MYRICARIA-HP ~
$ svnversion --help
usage: svnversion [OPTIONS] [WC_PATH [TRAIL_URL]]

from osgeo4w-msys from where I start package.sh osgeo4w-msys

myricaria@MYRICARIA-HP ~
$ echo $PATH
[...]
/c/Program Files/TortoiseSVN/bin: 
[...]

and in /c/Program Files/TortoiseSVN/bin: there is svnversion

so it's seems it's in $PATH, but not found by configure

[hamish]

Replying to hellik:

and in /c/Program Files/TortoiseSVN/bin: there is svnversion

so it's seems it's in $PATH, but not found by configure

from the subject of this bug it seems the issue has to do with building an official versioned release, not with a random svn snapshot build?

In that case the svn rev and thus svnversion are mostly irrelevant; ".svn/" metadata is not in the final tarball, and if a historian is curious what svn rev the version refers to they can always look it up in the tag's log. For versioned releases it already has an official version number, so we know exactly which version of the codebase the user is talking about- the point of including svn revs is to provide that info for non-official-versioned checkouts.

of course the packaging script should handle all the variable setting (or leaving blank) cleanly for you once you change the "Devel" keyword to "Release"...

Hamish

[hamish]

I'm not sure what the status of this one is, but it seems that building the RC4 wingrass package will be a good opportunity to field test what happens to the build when there is no .svn/ metadata in the tarball GRASS is built from.

Hamish

[hellik]

Replying to hamish:

from the subject of this bug it seems the issue has to do with building an official versioned release, not with a random svn snapshot build?

In that case the svn rev and thus svnversion are mostly irrelevant; ".svn/" metadata is not in the final tarball, and if a historian is curious what svn rev the version refers to they can always look it up in the tag's log.

see ​http://trac.osgeo.org/grass/browser/grass/branches/releasebranch_6_4/mswindows/GRASS-Installer.nsi.tmpl#L251

        !define /math VERSION ${SVN_REVISION} + ${BINARY_REVISION}

${VERSION} is used in the nsis-script/wingrass-installer to check if the installer is newer/older than the already installed

[hellik]

fixed by r59313