#3901: Addons missing in Makefile
-------------------------+-------------------------
Reporter: sbl | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone:
Component: Addons | Version: unspecified
Keywords: Makefile | CPU: Unspecified
Platform: Unspecified |
-------------------------+-------------------------
Several addons are missing in at least in https://github.com/OSGeo/grass-
addons/blob/master/grass7/raster/Makefile
If there is no specific reason for excluding them, missing addons should
be added so manuals are generated.
While this solution looks attractive (ok I didn't get it to work) there is
the issue of deprecated modules which are present yet not to be compiled
any more. A kind of filter would be needed.
As for the deprecated addons: couldn`t they be moved to a subdirectory
"deprecated" instead of kept together with recent addons? That might make
the situation even clearer?
With this change all Makefiles in raster, vector, temporal, imagery,
general would be identical. So it is probably better to include the
content of the Makefiles one level higher (meaning on the grass-
addon/grass7/ hierarchy?
Regarding the filtering of deprecated modules: What about adding a
deprecation warning to the manual instead of not building it? That way,
also deprecated modules can be discovered and inspected on the addon
manual website, but with a clear information that module ''r.in.whatever''
has been superseded by ''r.in.newandawsome'' (or what ever the reason for
the deprecation was)?
Replying to [comment:4 sbl]:
> Now, I updated the [https://github.com/OSGeo/grass-addons/pull/30 PR]
so, modules with a DEPRECATED file are filtered out. I would be glad if
someone could test it.
Great, thanks for the re-work (didn't test yet).
> With this change all Makefiles in raster, vector, temporal, imagery,
general would be identical. So it is probably better to include the
content of the Makefiles one level higher (meaning on the grass-
addon/grass7/ hierarchy?
... not sure what you mean?
> Regarding the filtering of deprecated modules: What about adding a
deprecation warning to the manual instead of not building it? That way,
also deprecated modules can be discovered and inspected on the addon
manual website, but with a clear information that module ''r.in.whatever''
has been superseded by ''r.in.newandawsome'' (or what ever the reason for
the deprecation was)?
I think that the overview page would become pretty cluttered. Maybe (in
case) in a separate section but overall, it would be an extra maintenance
burden for rather old code which if often not even any more compatible
with the current GRASS GIS libs.