Re: [GRASS-dev] check on GRASS revision number

2014-12-04 Thread Michael Barton
That’s very good to know. Michael C. Michael Barton Director, Center for Social Dynamics Complexity Professor of Anthropology, School of Human Evolution Social Change Head, Graduate Faculty in Complex Adaptive Systems Science Arizona State University voice: 480-965-6262

Re: [GRASS-dev] check on GRASS revision number

2014-12-02 Thread Markus Neteler
Hi, just for the record, by chance it happened to me today and how I solved it easily: GRASS 7.0.0svn (nc_spm_08_grass7):~ r.stream.order stream_rast=streams@user1 direction=direction@user1 elevation=elevation@PERMANENT accumulation=accum@user1 stream_vect=streams horton=horton ERROR: Module

Re: [GRASS-dev] check on GRASS revision number

2014-12-01 Thread Glynn Clements
Markus Metz wrote: Markus explained that this is for libgis only. That seems OK to me. My concern (based on the error message generated) is that this would block any module built against any version older than the current one being run. That seemed an unnecessarily strong check, but

Re: [GRASS-dev] check on GRASS revision number

2014-11-28 Thread Michael Barton
Markus explained that this is for libgis only. That seems OK to me. My concern (based on the error message generated) is that this would block any module built against any version older than the current one being run. That seemed an unnecessarily strong check, but apparently not what is

Re: [GRASS-dev] check on GRASS revision number

2014-11-27 Thread Glynn Clements
Michael Barton wrote: Why do we need to do this? Because getting developers to agree to maintaining a stable ABI (then ensuring that actually happens) appears to be beyond our capabilities. Probably the most common (and certainly the most obvious) example of incompatible changes (and the

Re: [GRASS-dev] check on GRASS revision number

2014-11-27 Thread Vaclav Petras
On Wed, Nov 26, 2014 at 2:13 PM, Michael Barton michael.bar...@asu.edu wrote: Why do we need to do this? From my experience it it good to have it. The risk of getting some cryptic errors is pretty high. This will tell you exactly what's happening before anything cryptic actually happens.

Re: [GRASS-dev] check on GRASS revision number

2014-11-26 Thread Martin Landa
Hi, 2014-11-26 19:32 GMT+01:00 Michael Barton michael.bar...@asu.edu: ERROR: Module built against version $Revision: 61095 $ but trying to use version $Revision: 62364 $. You need to rebuild GRASS GIS or untangle multiple installations. you need to rebuild extension

Re: [GRASS-dev] check on GRASS revision number

2014-11-26 Thread Michael Barton
Will this be the case for all extensions built against a revision of current - 1? If so, then there is no point in installing any binary module. Michael C. Michael Barton Director, Center for Social Dynamics Complexity Professor of Anthropology, School of Human Evolution

Re: [GRASS-dev] check on GRASS revision number

2014-11-26 Thread Markus Neteler
On Nov 26, 2014 8:02 PM, Michael Barton michael.bar...@asu.edu wrote: Will this be the case for all extensions built against a revision of current - 1? Today yes, due to an API change in libgis. If so, then there is no point in installing any binary module. Why? As soon as G7 is stable

Re: [GRASS-dev] check on GRASS revision number

2014-11-26 Thread Michael Barton
For any version of GRASS for which there is any reasonable development, all binary extensions will be out of date as soon as the first update is made. So they all will need to be recompiled. Why do we need to do this? Most will work fine without recompiling. Michael C.

Re: [GRASS-dev] check on GRASS revision number

2014-11-26 Thread Markus Neteler
On Wed, Nov 26, 2014 at 8:13 PM, Michael Barton michael.bar...@asu.edu wrote: For any version of GRASS for which there is any reasonable development, all binary extensions will be out of date as soon as the first update is made. No - as mentioned *only* is the libgis API is changed. Example: