How to only expose the public API of a project

[tclune]

I know that FORD has the ability to suppress (Fortran) PRIVATE items from the generated API, but this can be different than the public project API exposed to end users. E.g., a common pattern in our code is to have a per-directory "package" module that forms an explicit list of the items that are meant to be exposed to other layers. E.g.,

module MyPackage
   public
   use module_1, only: item_1
   use module_2, only: item_2
...

We don't expect anything fancy and automated (though that would be nice), but is there a way we can manually annotate our code so that only select items of the API are generated? I.e., we would go in and add some annotation in module_1 for procedure item_1 and module_2 for procedure item_2 to indicate that they should be generated. Or alternatively an annotation on all the other items in those modules that indicates not to generate their interface.

And of course we would still want to be able to generate the full API for developers. I.e., to ignore these annotations when desired.

[ZedThree]

I'm not sure there currently is anything that does exactly what you want.

You can put display: none in the module docstring. The module will get documented, but none of its children will. It seems display: none doesn't work at the source file level for some reason.

And it doesn't look like it's currently possible to override this in order to generate docs for the devs.

We could perhaps add a private: true or developer: true metadata attribute that would do something like this?

[tclune]

You can put display: none in the module docstring. The module will get documented, but none of its children will.

Unfortunately, something more fine-grained is needed for my purpose.

We could perhaps add a private: true or developer: true metadata attribute that would do something like this?

Yes - this is roughly what I envisioned, and then some per-procedure annotation to mark the procedure in a way that those attributes would control.

[tclune]

Adding @mathomp4 and @JulesKouatchou to monitor/comment this issue.