Massive slow down in docs generation

[ZedThree]

Just a heads up in case it wasn't noticed already: generating the docs went from taking 1m30s to ~1h10m with #772 (see previous action runs).

I think this is at least partly due to the larger number of entities that need processing (93454 vs 19548 previously), but there does also seem to be a general slow down which I've not investigated further. One workaround would be to explicitly exclude the new files.

As a separate issue, the formatting on these docstrings is probably not as intended. Ford ignores the first line of most of the new docstrings because they're in the form subroutine: start of doc comment which ford interprets (and then ignores as unknown) as a key: value config setting.

[jvdp1]

Thank you @ZedThree for reporting this issue.

I think this is at least partly due to the larger number of entities that need processing (93454 vs 19548 previously), but there does also seem to be a general slow down which I've not investigated further. One workaround would be to explicitly exclude the new files.

The issue is that ford ignores the cpp directives as it uses fypp as preprocessor. It is also due to the large number of new procedures (mostly BLAS/LAPACK). Ignoring them should be fine.

As a separate issue, the formatting on these docstrings is probably not as intended. Ford ignores the first line of most of the new docstrings because they're in the form subroutine: start of doc comment which ford interprets (and then ignores as unknown) as a key: value config setting.

Thank you. I will have a look.

[jvdp1]

As a separate issue, the formatting on these docstrings is probably not as intended. Ford ignores the first line of most of the new docstrings because they're in the form subroutine: start of doc comment which ford interprets (and then ignores as unknown) as a key: value config setting.

@perazz : could you consider this issue (even if those files will be currently ignored by ford), maybe by moving these docs inside the interface blocks (like for other stdlib modules)?

[ZedThree]

The issue is that ford ignores the cpp directives as it uses fypp as preprocessor.

One option could be to add a wrapper script that runs both preprocessors appropriately, and then use that script as the preprocessor for ford?

[perazz]

One option could be to add a wrapper script that runs both preprocessors appropriately

I don't think this is necessary: after the modifications in #786: all module procedures such as stdlib_dgemv are properly read in. Perhaps, FORD will also add interfaces to external subroutine dgemv, because it does not parse cpp directives, but this is not a problem: those externals are not public, they can't be used anywhere