-
Notifications
You must be signed in to change notification settings - Fork 582
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use Breathe for API Reference documentation #3377
Comments
Sounds good to me |
It does seem breathe is available in most distros https://repology.org/project/python:breathe/versions But the question arises what can/should we do if breathe is not available. Can we proceed with building the docs at that point, in some degraded fashion? Or is there no chance of proceeding? |
We can detect that breathe is not installed in the system (via
and simply leave out the Doxygen information. Probably, we could even mock breathe's directives in this case and render some "API documentation not available"-warning into the documentation in lieu of the actual breathe output. Is building the documentation on some restricted platform an actual use case though? |
Not really, but it would be nice if the user got basically working documentation even if they don't/can't have this extension installed for whatever reason. It sounds like things are fine in that regard. |
Status UpdateI think there's enough progress in converting the API reference to Breathe for today. I split the changes into small PRs (#3470, #3472, #3473, #3474, #3475, #3476, #3477, #3478) to ease the review a bit. A note on method: I went through the documentation in rST, moved extra detail over to the Doxygen comments where appropriatie and then replaced At some places I did find and fix minor documentation errors. Though, generally, these should happen in a separate pass. Chapters that still need attention
|
Lessons LearnedLets collect some lessons learned for our use case. In my opinion the main objective is not having to duplicate API documentation between header files (Doxygen) and Sphinx (rST). Below is an opinionated brain dump of my insights from the PRs created last week:
Like that Breathe this is just not feasible, I guess. 😢 |
Regardless of using Breathe or not: The current state of the documentation needs some TLC. The currently open (Breathe-related) PRs contain a number of cleanups and fixes to the documentation. If we decide to abandon Breathe, I could pull those out. Re:togglebutton: I'm sure we'd find a way to make this work without the dependency. Re:Breathe: I must say, I'm quite sad with this situation. I actually do enjoy the way Breathe bridges the gap between rST and Doxygen. Despite the lacking functionality and speed its a great tool, IMO. |
A note on performance: disabling source code listing in the XML output ( |
With I find that bearable for the convenience it brings. Also, I removed the @randombit If we decide to take this further, I'd be glad if we could start reviewing/merging the open PRs to reduce clutter. Otherwise, I'd like to rescue the API documentation fixes in them and then close them. Unfortunately, there doesn't seem to be a notable alternative to Breathe for our usecase. Except manual sync with the documentation as before or replacing the API docs in Sphinx with links to Doxygen. |
For the record: @lieser pointed out that people work on a speed improvement for Breathe. breathe-doc/breathe#962 |
We decided to drop the idea of integrating Breathe. Closing. |
Currently, the documentation in
docs/api_ref
duplicates quite a bit of the API details already documented in Doxygen. This adds a maintenance burden and leads to outdated documentation.Instead, I propose to use Breathe for our Sphinx documentation. This allows pulling API documentation from Doxygen into Sphinx documentation.
Example
Say, I want to describe the mandatory callbacks to be implemented by an application using TLS.
First I would use a doxygen member group to define the mandatory members in the code.
Then, instead of recreating all the information about the callback methods, one would simply add the following in the reStructuredText documentation for Sphinx:
And the result would look like that. Further tuning is possible, of course:
The text was updated successfully, but these errors were encountered: