[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Sphinx for QEMU docs? (and a doc-comment format questio

From: Paolo Bonzini
Subject: Re: [Qemu-devel] Sphinx for QEMU docs? (and a doc-comment format question)
Date: Wed, 9 Nov 2016 00:56:30 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0

On 07/11/2016 14:30, Stefan Hajnoczi wrote:
> On Sat, Nov 05, 2016 at 06:42:23PM +0000, Peter Maydell wrote:
>> In particular I think we could:
>>  * set up a framework for our in-tree docs/ which gives us a
>>    place to put new docs (both for-users and for-developers) --
>>    I think having someplace to put things will reduce the barrier
>>    to people writing useful new docs
>>  * gradually convert the existing docs to rst
>>  * use the sphinx extension features to pull in the doc-comments
>>    we have been fairly consistently writing over the last few years
>>    (for instance a converted version of docs/memory.txt could pull
>>    in doc comments from memory.h; or we can just write simple
>>    wrapper files like a "Bitmap operations" document that
>>    displays the doc comments from bitops.h)
> You are suggesting Sphinx for two different purposes:
> 1. Formatting docs/ in HTML, PDF, etc.
> 2. API documentation from doc comments.
> It's a good idea for #1 since we can then publish automated builds of
> the docs.  They will be easy to view and link to in a web browser.
> I'm not a fan of #2.  QEMU is not a C library that people develop
> against and our APIs are not stable.  There is no incentive for pretty
> doc comments.  It might be cool to set it up once but things will
> deterioate again quickly because we don't actually need external API
> docs.

I don't think pretty doc comments matter, but accurate doc comments do.
If we cannot have accurate doc comments, we might not have them at all,
but this is actually not the case.  There are some areas where we
actually go to great(er) lengths to have up-to-date documentation and
up-to-date doc comments, and it's a pity to only provide half of the
information in an easily consumable format.

It doesn't really have to be perfect, but it's a nice thing to have.
I'm not entirely sure that it's interesting to format bitops.h's doc
comments, but for memory.h or aio.h I'm pretty sure it's worth it.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]