linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
To: Linux Doc Mailing List <linux-doc@vger.kernel.org>,
	Jonathan Corbet <corbet@lwn.net>
Cc: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>,
	Mauro Carvalho Chehab <mchehab+huawei@kernel.org>,
	linux-kernel@vger.kernel.org, linux-kbuild@vger.kernel.org
Subject: [PATCH v3 0/2] add a make target to generate man pages from kernel-doc
Date: Wed, 27 Aug 2025 10:26:36 +0200	[thread overview]
Message-ID: <cover.1756282370.git.mchehab+huawei@kernel.org> (raw)

Hi Jon,

Currently, generation of manpages is hacky: one needs to run
kernel-doc over c source files and then use an extra script to
split results.

The new kernel-doc tool supports multiple files and even dirs,
so there's no need to use git ls-files anymore.

Yet, it produces a single output. Change the logic to add, instead
a target to docs Makefile to produce them, moving the split
and build logic to sphinx-build-wrapper.

That allows honoring SPHINXDIRS when they point to a subdir,
while scanning all files by default.

This series comes after:
    https://lore.kernel.org/linux-doc/cover.1756138805.git.mchehab+huawei@kernel.org/T/#t

-

It should be noticed that, while Sphinx does have a man pages
builder, it requires a completely different set of ReST entries
that would need to be designed specially for that:

- for each man page, an entry at conf.py is required;
- the ReST page should be in a format closer to a real man page;
- exactly one .rst file for each man page.

This is completely different than the approach we take where
we have, where kernel-doc direcly generates groff output
formated data.

So, yeah, this is still a little bit hackish, but to avoid
that we would need a completely different setup with, frankly,
would be a headache to setup and maintain.

With that in mind, there are a couple of possible alternatives:

1. change kernel-doc to produce one file per man page.
   A change like that would require adding file directory
   parameter for output, and/or teaching it about
   Documentation/output and O=;
2. make sphinx-build-wrapper do that for us. That's IMO
   the best alternative, which is what I actually implemented;
3. add a man pages Sphinx extension that would be tricking
   sphinx, making it produce one man page .rst file for each
   kernel-doc markup entry.
   This is probably doable, and could eventually bring some
   advantages, as we could also have man pages for pages 
   that are only in ReST format, but it will require some extra
   development, and likely require several changes at the
   existing .rst files. Also, generating extra output files out of
   the blue is something that Sphinx doesn't like to do, as it
   likes to have a 1:1 mapping between source files and output
   ones.
   Not sure if it worth the efforts, and will still be hackish.

I opted for (2), as it means that ones needing to generate
docs can benefit from SPHINXDIRS, and we don't need anything
extra at docs Makefile. By doing that, we can later improve the 
man pages logic without needing to touch anything else but
kernel-doc and/or the wrapper tool.

There are two points to consider:

- when SPHINXDIRS=. (the default), it searches fror all files
  treewide, even the ones without kernel-doc entries at docs,
  which is aligned with the procedure used by the current
  documentation about how to generate man pages;

- when SHINXDIRS=subdirs, it searches only for the files that
  come just after kernel-doc markups. It doesn't take into
  account any kernel-doc markup parameters to filter out
  internal/external functions or to point to an extra header
  file.

---

v3:
- fixed a badly-solved conflict on v2;
- improved documentation about manpages generation;
- added SEE ALSO at the man pages.

v2:
- no actual changes, but it was rebased on the top of the actual
  pacth series, in order to apply cleanly.
*** BLURB HERE ***

Mauro Carvalho Chehab (2):
  docs: add support to build manpages from kerneldoc output
  tools: kernel-doc: add a see also section at man pages

 Documentation/Makefile                 |  3 +-
 Documentation/doc-guide/kernel-doc.rst | 29 +++++----
 Makefile                               |  2 +-
 scripts/lib/kdoc/kdoc_files.py         |  5 +-
 scripts/lib/kdoc/kdoc_output.py        | 84 ++++++++++++++++++++++++--
 scripts/split-man.pl                   | 28 ---------
 tools/docs/sphinx-build-wrapper        | 81 +++++++++++++++++++++++--
 7 files changed, 178 insertions(+), 54 deletions(-)
 delete mode 100755 scripts/split-man.pl

-- 
2.51.0

             reply	other threads:[~2025-08-27  8:27 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-08-27  8:26 Mauro Carvalho Chehab [this message]
2025-08-27  8:26 ` [PATCH v3 1/2] docs: add support to build manpages from kerneldoc output Mauro Carvalho Chehab
2025-08-27 22:04   ` Nicolas Schier
2025-08-28 21:07     ` Mauro Carvalho Chehab
2025-08-27  8:26 ` [PATCH v3 2/2] tools: kernel-doc: add a see also section at man pages Mauro Carvalho Chehab

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=cover.1756282370.git.mchehab+huawei@kernel.org \
    --to=mchehab+huawei@kernel.org \
    --cc=corbet@lwn.net \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).