Dear coreboot Community,
Please be reminded that we have an upcoming leadership meeting scheduled for Wednesday, April 30, 2025. [1]
Kindly take a moment to update the agenda with matters you wish to see addressed during the meeting. [2] Thank you.
## Current Agenda Items
### [MartinR/Nicholas Chin] Look at adding doxygen back to coreboot * (https://review.coreboot.org/c/coreboot/+/8722) [RFC][POC] Tree: Add doxygen config files and targets * coreboot used to have targets to build Doxygen documentation, but they were removed in (https://review.coreboot.org/q/commit:619086d1056c) ("Treewide: Remove doxygen config files and targets") after it was decided that the doxygen documentation was dead. Recent discussion on a patch for doc.coreboot.org brought up the issue of how to keep API documentation up to date with the code, and there was some interest in being able to use the docstrings in the code to generate such information. Doxygen is one of the go-to tools for this sort of thing, but the previous attempt at using this required users to run a separate make target to view documentation, which may have contributed to its lack of use. Instead of using Doxygen to generate its own separate HTML output directly, there are tools such as Breathe [1], which can take the output of Doxygen and bridge it into Sphinx, which would allow API documentation to be seamlessly integrated into doc.coreboot.org and built automatically. To support this, re-add Doxygen configs and targets, but configure it for XML output, which is the format Breathe is able to parse. * The Gerrit discussion that prompted this idea: (https://review.coreboot.org/c/coreboot/+/87186/4..5/Documentation/lib/timest...) * A proof of concept for how the whole Doxygen + Breathe thing works to pull in docstrings into our docs can be found in these patches: (https://review.coreboot.org/q/topic:%22autogen_api_docs%22) * There are also some alternatives which are all based around the idea of “API docs in code, then generate documentation from that.” The Sphinx syntax for pulling in a particular API’s documentation is also fairly similar between them. * With all of these types of documentation generators, you only need to add Doxygen/kerneldoc/etc style docstring comments for the APIs you intend to include in the documentation, and in the Documentation/*.md files you need to explicitly add a directive to pull in the docstrings for those items. This is in comparison to pure Doxygen documentation which runs and generates docs for the entire tree (it is possible to exclude certain subdirectories but in general it is designed to run on the the entire project) * [NicholasC] kerneldoc from Linux (basically their own Doxygen-like tool) * I did some brief experimentation with this and it also seems to work fairly well. It does seem lighter than Doxygen + Breathe and is much faster than my current proof of concept. I think this would also be easier to integrate into the doc.coreboot.org container as it doesn’t require a separate step to run like Doxygen. That was causing me a lot of issues in the container due to the tree being read-only and the output paths being different compared to running in the host OS. There might be some Linux-isms that we’d need to deal with though, whereas Doxygen is a bit more generic. * Proof of concept here: (https://review.coreboot.org/q/topic:%22docs-kernel-doc%22) (this does currently work in Docker, unlike my current Doxygen + Breathe proof of concept.) * Sphinx C Autodoc (https://sphinx-c-autodoc.readthedocs.io/en/latest/) * Relies on clang, and I found it difficult to figure out all the proper compiler flags to pass it to get it to work * Hawkmoth (https://jnikula.github.io/hawkmoth/stable/) * Also relies on clang; had the same issues as the above
### [MartinR] Leadership meeting for Asia times * (https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/thread/UMGFE...)
### [Martinr/Michał Żygowski] redundancy of firmware with vboot * (https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/thread/IY6B2...)
[1](https://coreboot.org/calendar.html) [2](https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkKrgKj...)