Opened 11 years ago
Closed 11 years ago
#1940 closed defect (fixed)
wingrass - nsis - script in release mode: !define SVN_REVISION "@GRASS_VERSION_SVN@" not set
Reported by: | hellik | Owned by: | martinl |
---|---|---|---|
Priority: | critical | Milestone: | 6.4.3 |
Component: | Packaging | Version: | 6.4.3 RCs |
Keywords: | nsis, wingrass | Cc: | grass-dev@… |
CPU: | x86-64 | Platform: | MSWindows 7 |
Description
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"
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" [...]
251 !define /math VERSION ${SVN_REVISION} + ${BINARY_REVISION}
doesn't work and nsis stopps with an error
Change History (15)
comment:1 by , 11 years ago
follow-ups: 4 6 comment:2 by , 11 years ago
Replying to hellik:
> 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
> 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
)?
comment:3 by , 11 years ago
Cc: | added |
---|
follow-up: 5 comment:4 by , 11 years ago
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 runningconfigure
)?
source code downloaded from SVN? If you use tarball, it will fail (missing svn number).
comment:5 by , 11 years ago
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 runningconfigure
)?source code downloaded from SVN? If you use tarball, it will fail (missing svn number).
source was from a svn check out
follow-up: 9 comment:6 by , 11 years ago
Replying to martinl:
Do you have
svnversion
in the path (when runningconfigure
)?
from the msys-cmdline
myricaria@MYRICARIA-HP ~ $ svnversion --version svnversion, version 1.7.0 (r1176462) compiled Oct 10 2011, 22:03:27
follow-up: 8 comment:7 by , 11 years ago
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
comment:8 by , 11 years ago
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
follow-up: 10 comment:9 by , 11 years ago
Replying to hellik:
Replying to martinl:
Do you have
svnversion
in the path (when runningconfigure
)?
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
. (?)
follow-up: 11 comment:10 by , 11 years ago
Replying to martinl:
Replying to hellik:
Replying to martinl:
Do you have
svnversion
in the path (when runningconfigure
)?When you launch
configure
or betterpackage.sh
you should get (seepackage.log
)checking for svnversion... /c/Subversion/svnversion
include/Make/Grass
should containGRASS_VERSION_SVN = XXXXXXIn other words, try to check if
svnversion
is in the path when runningpackage.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
follow-up: 13 comment:11 by , 11 years ago
Keywords: | wingrass added |
---|
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
comment:12 by , 11 years ago
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
comment:13 by , 11 years ago
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.
!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
comment:14 by , 11 years ago
Cc: | added; removed |
---|---|
Owner: | changed from | to
Replying to hellik:
source get by a svn checkout