g.extension: default url should not point to grass7

[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 ?

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 ?

Moritz

[martinl]

Replying to 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.

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.

Martin

[mlennert]

Replying to martinl:

Replying to 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 ?

Moritz

[martinl]

Replying to 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).

[mlennert]

Replying to martinl:

Replying to 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).

Ok, in light of this I'm closing bug as invalid.

Moritz

[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?

Perhaps something with 'svn add' + 'svn:special'.

​http://subversion.tigris.org/faq.html#symlinks

The idea is to avoid the double effort of keeping the two "branches" in sync.

Hamish

[martinl]

Replying to 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.

Patch again trunk could avoid it.

Martin

[martinl]

Replying to martinl:

Patch again trunk could avoid it.

Ops, typo, I meant a patch which enables compiling against trunk.

[hamish]

Replying to 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.

2c, Hamish