Opened 11 years ago

Closed 11 years ago

Last modified 11 years ago

#684 closed defect (invalid)

g.extension: default url should not point to grass7

Reported by: mlennert Owned by: grass-dev@…
Priority: normal Milestone: 7.0.0
Component: Default Version: svn-trunk
Keywords: g.extension Cc:
CPU: Unspecified Platform: Unspecified

Description

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

Change History (8)

comment:1 in reply to:  description ; Changed 11 years ago by martinl

Milestone: 6.5.07.0.0
Version: 6.4.0 RCssvn-trunk

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

comment:2 in reply to:  1 ; Changed 11 years ago by 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

comment:3 in reply to:  2 ; Changed 11 years ago by 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).

comment:4 in reply to:  3 Changed 11 years ago by mlennert

Resolution: invalid
Status: newclosed

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

comment:5 Changed 11 years ago 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?

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

comment:6 in reply to:  5 ; Changed 11 years ago by 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

comment:7 in reply to:  6 Changed 11 years ago by martinl

Replying to martinl:

Patch again trunk could avoid it.

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

comment:8 in reply to:  1 Changed 11 years ago by 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

Note: See TracTickets for help on using tickets.