Addons missing in Makefile

[sbl]

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.

Maybe even better do point to all subdirectories in raster, vector, ... by default? E.g. like here:

​https://stackoverflow.com/questions/17834582/run-make-in-each-subdirectory

Then addon devs do not have to remember this...

[neteler]

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.

[sbl]

See: ​https://github.com/OSGeo/grass-addons/pull/30 for an example Makefile.

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?

[neteler]

Testing PR 30:

(@devs, in case you didn't know - you can add .diff to a pull request on GH and get the patch as diff file)

cd grass_addons_git/
# fetching diff
wget https://patch-diff.githubusercontent.com/raw/OSGeo/grass-addons/pull/30.diff
patch -p1 < 30.diff 

cd grass7/raster/

G78SRC="~/software/grass78_git"

# compile against G78 (adapt path as needed)
make MODULE_TOPDIR=$G78SRC

# check for errors
cat $G78SRC/error.log

Tested locally, the proposed ​https://github.com/OSGeo/grass-addons/pull/30 works fine, great idea!

TODO: ignore the subdirs which contain a DEPRECATED file.

[sbl]

Now, I updated the ​PR so, modules with a DEPRECATED file are filtered out. I would be glad if someone could test it.

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

[neteler]

Replying to sbl:

Now, I updated the ​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.

[sbl]

With ​https://github.com/OSGeo/grass-addons/pull/30 merged, this can be closed.