Hi,
from a current question in the grass-gui list:
"...GIS Library Revision is 45934 (2011-4-13)..."
I wonder if we need to keep this info in g.version. I find it rather
confusing. The SVN revision is the better (and relevant) information.
Can we (please) ditch this "GIS Library Revision" output?
Markus
Markus N wrote:
from a current question in the grass-gui list:
"...GIS Library Revision is 45934 (2011-4-13)..."I wonder if we need to keep this info in g.version. I find
it rather confusing. The SVN revision is the better (and
relevant) information.Can we (please) ditch this "GIS Library Revision" output?
Hi,
that is the one which needs to be consistent for e.g. locally
compiled modules to work with the current GRASS's libgis API.
Also, that one is guaranteed to be there, but perhaps the svn-
version one is not? (e.g. in the release tarballs there are no
.svn/ dirs for ./configure to query about the overall rev #,
but GIS_H_VERSION date is embedded in gis.h at commit time)
maybe the error message if you try to run an api-mismatched
module gives all the info already, or maybe the description
of what it is could be better worded to show the data by a
less confusing to non-devs way?
note also discussion about this in the g.version ticket on trac.
Hamish
Markus Neteler wrote:
from a current question in the grass-gui list:
"...GIS Library Revision is 45934 (2011-4-13)..."I wonder if we need to keep this info in g.version. I find it rather
confusing. The SVN revision is the better (and relevant) information.Can we (please) ditch this "GIS Library Revision" output?
The SVN revision is only available if GRASS was built from a source
tree obtained from SVN (as opposed to e.g. a snapshot tarball) and if
the svnversion program is installed on the build system.
And if you do "svn update ; make clean ; make" (without re-running
configure), the reported SVN revision will be that at the time that
configure was last run, not that of the code being compiled.
The gis.h version is always available, reflects the version of gis.h
being used (regardless of when configure was run), and (as Hamish
points out) is the version used for the libgis consistency check.
If you don't want to know the gis.h version, don't use the -r flag,
but there's no good reason to remove that functionality.
--
Glynn Clements <glynn@gclements.plus.com>
Ok, thanks for the explanations.
The only remaining issue (for me) is that 2011 is indicated which
quite not reflects the current state. But of course that's not so
important...
Markus
Markus Neteler wrote:
Ok, thanks for the explanations.
The only remaining issue (for me) is that 2011 is indicated
which quite not reflects the current state. But of course that's
not so important...
probably the best thing we can do is adjust the wording to make
it clear to non-programmers what it is refering to. Which is
tricky to get right, but not an impossible task.
(I've no great suggestions)
Hamish