From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S964986AbcAZMRJ (ORCPT ); Tue, 26 Jan 2016 07:17:09 -0500 Received: from mail-ob0-f173.google.com ([209.85.214.173]:34449 "EHLO mail-ob0-f173.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755079AbcAZMRF (ORCPT ); Tue, 26 Jan 2016 07:17:05 -0500 MIME-Version: 1.0 X-Originating-IP: [2a02:168:56c9:0:22cf:30ff:fe4c:37d6] In-Reply-To: References: <1453764522-29030-1-git-send-email-corbet@lwn.net> Date: Tue, 26 Jan 2016 13:17:04 +0100 Message-ID: Subject: Re: [RFC] A first shot at asciidoc-based formatted docs From: Daniel Vetter To: Jani Nikula Cc: Jonathan Corbet , linux-doc@vger.kernel.org, Linux Kernel Mailing List Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jan 26, 2016 at 1:08 PM, Jani Nikula wrote: > On Tue, 26 Jan 2016, Jonathan Corbet wrote: >> So here is a proof-of-concept series showing how a fully asciidoc-based >> toolchain might work. Lots of hackery here, this isn't meant to be applied >> to anything at this point, but it's a good start. What this series has is: >> >> - Jani Nikula's patch adding asciidoc output to kernel-doc. Thanks for >> doing this! It was the kickstart that was needed to get this process >> going. > > Hooray! :) > >> - Tweak docproc to handle asciidoc template files. If a template ends in >> ".adt", it's an asciidoc template; it's processed pretty much the same >> way, except that kernel-doc gets the -asciidoc argument. >> >> - Bash on the Makefile to get it to process asciidoc templates into HTML. >> Naturally this was where most of the time got spent. *Only* HTML output >> works at the moment. >> >> - Convert tracepoints.html to tpoint.adt as a proof of concept. It works, >> and the output is much pleasing, IMO. >> >> I'm sure there's a thousand details to deal with, and there is the issue of >> the other output formats. asciidoctor claims to be able to create man >> pages, but I've not tried that yet; neither tool will do PDF. Maybe we >> could rely on pandoc to do that. Otherwise, getting to asciidoc to XML is >> straightforward, so it should be possible to use xmlto as is done now. >> >> It's all in the doc/asciidoc branch of git://git.lwn.net/linux.git if >> anybody wants to mess with it. >> >> Comments? > > I'm afraid we've done some overlapping work in the mean time, but I'm > happy we've both looked at the tool chain, and can have a more > meaningful conversation now. > > I first took roughly the same approach as you did. I was really > impressed with the speed and the beauty of the produced HTML. The > trouble is, neither asciidoc nor asciidoctor can produce chunked (split > to several pages) HTML directly. This is a showstopper for the gpu > document which turns into 1.3 MB of HTML, which looks pretty but is a > paint to navigate. To do chunked output, you have to output DocBook and > handle that like we do now. So while I would like to have asciidoc > generate HTML directly for speed and beauty, I ended up going the > asciidoc to DocBook path. The upside is all the output formats are > supported. This is a big bummer since with the parralized kernel-doc processing using Makefiles and using asciidoctor even building something big like the gpu docs is down to 2-3 seconds. From a clean tree, so not even counting incremental speed-ups. Unfortunately asciidoc doesn't have an built-in tooling (there's some experimental extensions) to split things up. -Daniel > (We could of course split the source documents, but then I believe we'd > have lots of trouble cross-referencing between the documents. I could be > proven wrong. I'd *like* to be proven wrong.) > > One significant difference between our approaches is that I ditched > docproc out of the equation. Instead of having the docproc ! directives > in the asciidoc, I opted for using asciidoc's native include macro, with > specially crafted filename suffixes to specify what parts of the source > to include. Those files are then generated as intermediate asciidoc > files using kernel-doc, with dependencies set right. There's a bunch of > scripting involved, but it's pretty straight forward. > > So you'd have, for example, > > include::drivers/gpu/drm/drm_ioctl.c,export[] > > to include all the exported functions, or > > include::drivers/gpu/drm/i915/i915_irq.c,doc,interrupt_handling[] > > to include the DOC: section. I think I'd like some version of this, > regardless of whether asciidoc generates HTML or DocBook. It lets make > parallelize all of kernel-doc processing for free, which is a big win. > > Patches follow, also available in kernel-asciidoc branch of > git://people.freedesktop.org/~jani/drm (web interface > http://cgit.freedesktop.org/~jani/drm/log/?h=kernel-asciidoc) > > BR, > Jani. > > > Jani Nikula (10): > kernel-doc: rewrite usage description, remove duplicated comments > kernel-doc: add support for asciidoc output > kernel-doc: support printing exported and non-exported symbols > kernel-doc: add support for printing DOC: comments with escaped names > scripts: add asciidoc-includes to extract includes from asciidoc > scripts: add a kernel-doc helper for special invocation > scripts: add tool for generating asciidoc dependencies and rules > scripts: add a crude converter from DocBook tmpl to asciidoc > Documentation: convert gpu.tmpl to gpu.txt > Documentation: build asciidoc documentation > > Documentation/DocBook/Makefile | 37 +- > Documentation/DocBook/gpu.tmpl | 3499 ---------------------------------------- > Documentation/DocBook/gpu.txt | 1183 ++++++++++++++ > scripts/asciidoc-includes | 6 + > scripts/kernel-doc | 365 ++++- > scripts/kernel-doc-deps | 66 + > scripts/kernel-doc-helper | 70 + > scripts/tmpl2asciidoc | 39 + > 8 files changed, 1709 insertions(+), 3556 deletions(-) > delete mode 100644 Documentation/DocBook/gpu.tmpl > create mode 100644 Documentation/DocBook/gpu.txt > create mode 100755 scripts/asciidoc-includes > create mode 100755 scripts/kernel-doc-deps > create mode 100755 scripts/kernel-doc-helper > create mode 100755 scripts/tmpl2asciidoc > > -- > 2.1.4 > -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch