[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160213145317.247c63c7@lwn.net>
Date: Sat, 13 Feb 2016 14:53:17 -0700
From: Jonathan Corbet <corbet@....net>
To: LKML <linux-kernel@...r.kernel.org>, linux-doc@...r.kernel.org,
Keith Packard <keithp@...thp.com>,
Jani Nikula <jani.nikula@...el.com>,
Daniel Vetter <daniel.vetter@...ll.ch>
Subject: Kernel docs: muddying the waters a bit
So I fear you all are going to hate me for this...
Asciidoc is a credible solution to the formatted documentation problem,
but it's not the only such; I'd like to be sure that we pick the right
one. I worry that asciidoc seems to be aimed mostly at small documents,
and that the project itself seems a little lifeless - it's not a good
sign when your main page's link to the repository has been dead for a long
time. (Asciidoctor seems more active, with the Github folks behind it,
but that means bringing Ruby into the picture).
An alternative we haven't really looked at yet is ReStructuredText (or
"RST") and the Sphinx system (sphinx-doc.org) built on top of it. RST is
YA simple markup scheme, remarkably similar to Markdown or Asciidoc;
Sphinx is a fairly sophisticated documentation system that uses RST.
I spent a few hours reworking the asciidoc patches to do RST instead, then
built a few template files' worth of docs. The result can be seen at:
http://static.lwn.net/kerneldoc/
It's very much a POC (however you might want to define the term), there's
lots of glitches, I chose a theme pretty much at random, etc. But it
shows that it can be done.
Like asciidoc, Sphinx is Python-based, so it adds little to the toolchain
requirements there. It produces integrated, multi-file HTML natively,
with a TOC, an index, cross-file cross references, and more. It can make
things like function indexes. It claims output in epub, docbook, and man
(I've not yet messed with those). The path to PDF is via latex; clearly
the docbook path could be used too.
I used my same docproc hack to extract the comments here, mostly because I
had it at hand. We could go with Jani's separate-file approach if we
wanted. There's also a tool out there (called "breathe") that's meant to
turn doxygen-style comments into RST; I haven't had a chance to mess with
it. We *could* also write an extension to pull the comments directly in
Sphinx if there were a compelling reason to do so.
If anybody's curious, the work done to get this far is in:
git://git.lwn.net/linux.git doc/sphinx
but it looks suspiciously like the previous asciidoc patches, and, in any
case, it would have to be thrown out, publicly disowned, and replaced
before going any further with this, should that be what we decide to do.
So can we discuss? I'm not saying we have to use Sphinx, but, should we
choose not to, we should do so with open eyes and good reasons for the
course we do take. What do you all think?
jon
Powered by blists - more mailing lists