[suggest moving this to the grass-dev ML]
Markus Metz wrote:
>> I have renamed the grass-addons directory r.univar2.zonal to
>> r.univar.zonal in r43802.
>
> Thanks for that. Yet no success since g.extension in
GRASS 6 seems to fail on multi-target Makefiles.OK, suggested remedy:
1) in 6.5 and trunk replace r.univar with r.univar.zonal
because without the zones option, r.univar.zonal behaves
exactly like r.univar, and r.univar.zonal seems to be a
popular addon
(at some stage v.rast.stats should also be replaced)
I am not so happy for these renamings and backports all to please
an overly brittle build system. better to fix the problem for
all at the source instead.
for 6.5svn I would vote to add .zonal as another module if you
like, but do not replace r.univar.
for trunk we could replace, but only after a full and serious
audit that they are really in sync and nothing has been lost. I
don't want another situation like we had for merging r.sun2, and
r.univar is diverging far enough away from the original k.i.s.s.
design that I find it harder now to effectively audit and
maintain without a major investment of time.
2) as an addon for 64, split r.univar.zonal in r.univar.zonal
and r3.univar.zonal with conventional Makefile targets to make
g.extension happy
better: make g.extension more flexible/aware.
regards,
Hamish
ps- still need to test the new experimental g.extension changes
in 6.5svn and port them through to the python version in trunk
if people approve of the ideas. feedback requested.