Skip to content
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

docs: Generate documentation from the kconfig files #3608

Draft
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

btashton
Copy link
Contributor

Summary

This generates documentation as reference that can be used from the Kconfig files.

This is not ready to merge this is just for feedback on the idea. I am still trying to figure out what the best way to make this work is. Building all of this take a long time for sphinx on the first pass as it generates ~16000 files. Other projects that do something similar just create a stub file for the references that can be used for normal building and only when you want to build the final documentation package do you generate the full rendering of the pages, I think that would be very reasonable.

The output looks something like this with all the CONFIG_ as references that you can click

image

@btashton btashton force-pushed the kconfig-docs branch 6 times, most recently from 259f1aa to 5f2e0c8 Compare April 26, 2021 09:15
@davids5
Copy link
Contributor

davids5 commented Apr 26, 2021

@btashton - I think this is great! It also has as side benefit of us putting more effort into more detailed help in the Kconfig files. Sometimes even a one line of explanation can save lots of grepping.

@acassis
Copy link
Contributor

acassis commented Apr 26, 2021

This is a great idea! I think it also will spot many Kconfig entry that are missing Help information!

@patacongo
Copy link
Contributor

There is a tool at tools/mkconfigvars.sh and tools/kconfig2html.c that I used to use to generate online configuration variable documentation. It would generate a 10Mb or so HTML file with collapsible hyperlinked TOC and cross-referenced dependencies.

@patacongo
Copy link
Contributor

There is a tool at tools/mkconfigvars.sh and tools/kconfig2html.c that I used to use to generate online configuration variable documentation. It would generate a 10Mb or so HTML file with collapsible hyperlinked TOC and cross-referenced dependencies.

There is still a very old generated HTML file online: https://cwiki.apache.org/confluence/display/NUTTX/Configuration+Variables

That should be removed. It is way out of date. I would update that file on each release so that it reflects the current state of configuration variables.

@protobits
Copy link
Contributor

Nice. I always thought this would be good to have, accompanied with a sphinx role such as :kconfig:<config var> which would link to the documentation of the variable. Maybe we can look into how to achieve that.
BTW, together with the CMake system I intend to have a specific documentation section such as "Build System". I imagine This section be a sibling of this one. I tried to think of a top-level section that could group these and other related sections but I can't come up with an appropriate name. I thought about something like "Developer Guide" (which also allows for other sections explaining how to add new board, app, arch, etc.). What do you think?

@protobits
Copy link
Contributor

BTW, why 16000 files? Do we have 16000 config vars??

{% if node.include_path %}
Included via: {% for filename, linenr in node.include_path %}``{{filename}}:{{linenr}}``{% if not loop.last %} -> {% endif %}{% endfor %}
{% endif %}
Menu path: (Top) -> {% for node_p in top_to_node(node) %}{% if node_p.prompt %}{{node_p.prompt[0]}}{% else %}{{kconfiglib.standard_sc_expr_str(node_p.item)}}{% endif %}{% if not loop.last %} -> {% endif %}{% endfor %}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Use :menuselection: for nicer rendering as explain here: https://nuttx.apache.org/docs/latest/contributing/documentation.html#user-indications

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is different. This is menu as in Kconfig menu

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.


At ``{{node.filename}}:{{node.linenr}}``
{% if node.include_path %}
Included via: {% for filename, linenr in node.include_path %}``{{filename}}:{{linenr}}``{% if not loop.last %} -> {% endif %}{% endfor %}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We could probably use :file: for filenames and later generate links to GitHub (to master or appropriate tag).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like this idea. Not quite sure how we would handle this cross repo, but something to think about.

@btashton
Copy link
Contributor Author

btashton commented Apr 26, 2021

Nice. I always thought this would be good to have, accompanied with a sphinx role such as :kconfig:<config var> which would link to the documentation of the variable. Maybe we can look into how to achieve that.

This already does that you just have to do :option:`CONFIG_FOO` and it will create the reference for you.

This was actually my main motivation because I want to link to this from the board documentation so we can stop documenting the same things over and over with stale information.

As for the 16000 files yes there are that many configuration variable. Most of them are arch and chip specific.

@btashton
Copy link
Contributor Author

@hartmannathan this was my stab at this feature

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants