Preliminary support for API docs generation via FORD
For now we set uncommon UTF-8 characters as [pre]docmark[_alt] symbols,
so to (almost)^ deactivate docstring generation: better nothing than a total mess.
^ We say almost cause there is some bug / misunderstanding on how to override
default dockmark_alt and predockmark_alt symbols, so we still get some noise.
Gradually we'd want to parse and standardize the comments across all the
modules (currently there are many different styles, so whatever marker set
we choose, the output is very messy). There is no need to conform to
the defaults of FORD, but some convention has to be taken (and followed).
Even without docstrings the generated html provides already significant
value: all procedures/types/interfaces are searchable, without the usual
noise that grep or similar tools generate (as calls and references are
picked too), all dependencies / call-graphs / inheritance-graphs / etc.
are generated and nicely displayed in the resulting html, which can be
easily uploaded in a github page (and an action for that has been already
set up).
Some well-defined refactoring has been made to the source code, with the
aim to ease the parsing for FORD (as well as improving the codebase itself).
Specifically:
fix some non UTF-8 characters within special_functions.f90 (see 455dff5f6e0193fffa31b816836fb8bcf6085607)
make ioread_control.f90 a proper (external) subroutine instead of just an included 'code-snippet' (see a2cd2b7aba019ae411a126b75ec92311ecab7f72)
Preliminary support for API docs generation via FORD
For now we set uncommon UTF-8 characters as
[pre]docmark[_alt]symbols, so to (almost)^ deactivate docstring generation: better nothing than a total mess.^ We say almost cause there is some bug / misunderstanding on how to override default dockmark_alt and predockmark_alt symbols, so we still get some noise.
Gradually we'd want to parse and standardize the comments across all the modules (currently there are many different styles, so whatever marker set we choose, the output is very messy). There is no need to conform to the defaults of FORD, but some convention has to be taken (and followed).
Even without docstrings the generated html provides already significant value: all procedures/types/interfaces are searchable, without the usual noise that grep or similar tools generate (as calls and references are picked too), all dependencies / call-graphs / inheritance-graphs / etc. are generated and nicely displayed in the resulting html, which can be easily uploaded in a github page (and an action for that has been already set up).
Some well-defined refactoring has been made to the source code, with the aim to ease the parsing for FORD (as well as improving the codebase itself).
Specifically:
special_functions.f90(see 455dff5f6e0193fffa31b816836fb8bcf6085607)ioread_control.f90a proper (external) subroutine instead of just an included 'code-snippet' (see a2cd2b7aba019ae411a126b75ec92311ecab7f72)