This then also raises the question whether having a separate grass7
directory in that tree is really useful. Shouldn't AddOns just declare in
README's that they are only usable in a specific grass version ?
I think that g.extension from trunk should point to GRASS 7 compatibile
modules.
> This then also raises the question whether having a separate grass7
directory in that tree is really useful. Shouldn't AddOns just declare in
README's that they are only usable in a specific grass version ?
Another options would to provide patch for GRASS7. E.g. g.extension could
check if dictionary contains {{{grass7.diff}}} and patch the source code
before compilation.
#684: g.extension: default url should not point to grass7
--------------------------+-------------------------------------------------
Reporter: mlennert | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: normal | Milestone: 7.0.0
Component: default | Version: svn-trunk
Resolution: | Keywords: g.extension
Platform: Unspecified | Cpu: Unspecified
--------------------------+-------------------------------------------------
Comment (by mlennert):
Replying to [comment:1 martinl]:
> Replying to [ticket:684 mlennert]:
> > g.extension proposes the following default URL for downloading AddOns:
> >
> > https://svn.osgeo.org/grass/grass-addons/grass7
> >
> > However, most AddOns are in
> >
> > https://svn.osgeo.org/grass/grass-addons/
> >
> > Shouldn't the default rather point there ?
>
> I think that g.extension from trunk should point to GRASS 7 compatibile
modules.
Aren't most modules in the main directory also GRASS 7 compatible ? What
defines this compatibility ?
#684: g.extension: default url should not point to grass7
--------------------------+-------------------------------------------------
Reporter: mlennert | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: normal | Milestone: 7.0.0
Component: default | Version: svn-trunk
Resolution: | Keywords: g.extension
Platform: Unspecified | Cpu: Unspecified
--------------------------+-------------------------------------------------
Comment (by martinl):
Replying to [comment:2 mlennert]:
> > I think that g.extension from trunk should point to GRASS 7
compatibile modules.
>
> Aren't most modules in the main directory also GRASS 7 compatible ? What
defines this compatibility ?
I don't think so, C/C++ modules needs to be updated to use rasterlib.
Shell script modules need to be rewritten to Python (not obligatory, but
wanted).
#684: g.extension: default url should not point to grass7
--------------------------+-------------------------------------------------
Reporter: mlennert | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: closed
Priority: normal | Milestone: 7.0.0
Component: default | Version: svn-trunk
Resolution: invalid | Keywords: g.extension
Platform: Unspecified | Cpu: Unspecified
--------------------------+-------------------------------------------------
Changes (by mlennert):
* status: new => closed
* resolution: => invalid
Comment:
Replying to [comment:3 martinl]:
> Replying to [comment:2 mlennert]:
>
> > > I think that g.extension from trunk should point to GRASS 7
compatibile modules.
> >
> > Aren't most modules in the main directory also GRASS 7 compatible ?
What defines this compatibility ?
>
> I don't think so, C/C++ modules needs to be updated to use rasterlib.
Shell script modules need to be rewritten to Python (not obligatory, but
wanted).
#684: g.extension: default url should not point to grass7
--------------------------+-------------------------------------------------
Reporter: mlennert | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: closed
Priority: normal | Milestone: 7.0.0
Component: default | Version: svn-trunk
Resolution: invalid | Keywords: g.extension
Platform: Unspecified | Cpu: Unspecified
--------------------------+-------------------------------------------------
Comment (by hamish):
I wonder for cases where it is known that the (e.g. C vector) module needs
no porting changes if it is possible to symlink the module dir into the
grass7 addons svn?
#684: g.extension: default url should not point to grass7
--------------------------+-------------------------------------------------
Reporter: mlennert | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: closed
Priority: normal | Milestone: 7.0.0
Component: default | Version: svn-trunk
Resolution: invalid | Keywords: g.extension
Platform: Unspecified | Cpu: Unspecified
--------------------------+-------------------------------------------------
Comment (by martinl):
Replying to [comment:5 hamish]:
> I wonder for cases where it is known that the (e.g. C vector) module
needs no porting changes if it is possible to symlink the module dir into
the grass7 addons svn?
At least you need to replace
{{{ #include <grass/Vect.h>
}}}
by
{{{ #include <grass/vector.h>
}}}
> The idea is to avoid the double effort of keeping the two "branches" in
sync.
#684: g.extension: default url should not point to grass7
--------------------------+-------------------------------------------------
Reporter: mlennert | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: closed
Priority: normal | Milestone: 7.0.0
Component: default | Version: svn-trunk
Resolution: invalid | Keywords: g.extension
Platform: Unspecified | Cpu: Unspecified
--------------------------+-------------------------------------------------
Comment (by hamish):
Replying to [comment:1 martinl]:
> Another options would to provide patch for GRASS7. E.g. g.extension
> could check if dictionary contains {{{grass7.diff}}} and patch the
> source code before compilation.
FWIW I have and do use a similar approach in a few other projects. (mostly
debian packaging patches to allow things to also work on ubuntu, 64bit
versions, etc)
All in all I have not enjoyed the experience, I have found it quite
painful to maintain/rebuild the patch sets every time a change is applied
in trunk.
but YMMV and I may well be going about it the hard way.