From: Peter Maydell <peter.maydell@linaro.org>
To: qemu-devel@nongnu.org
Cc: Paolo Bonzini <pbonzini@redhat.com>,
Markus Armbruster <armbru@redhat.com>,
Maxim Cournoyer <maxim.cournoyer@gmail.com>
Subject: [RFC 0/2] Build a single Sphinx manual, not five
Date: Mon, 9 Nov 2020 21:44:18 +0000 [thread overview]
Message-ID: <20201109214420.32131-1-peter.maydell@linaro.org> (raw)
When we first converted our documentation to Sphinx, we split it into
multiple manuals (system, interop, tools, etc), which are all built
separately. The primary driver for this was wanting to be able to
avoid shipping the 'devel' manual to end-users. However, this is
working against the grain of the way Sphinx wants to be used and
causes some annoyances:
* Cross-references between documents become much harder or
possibly impossible (currently we don't even try)
* There is no single index to the whole documentation
* Within one manual there's no links or table-of-contents info
that lets you easily navigate to the others
* The devel manual doesn't get published on the QEMU website
(it would be nice to able to refer to it there)
* Common information like the QEMU license, supported platforms,
and deprecation information either gets duplicated across manuals,
split between them, or shoved into the system manual as the
closest to a generic one
Merely hiding our developer documentation from end users seems like
it's not enough benefit for these costs.
This RFC series switches over to building a single big manual,
the same way that the readthedocs version builds it.
Patch 1 in the set suppresses the warnings that would otherwise
be caused by the handful of 'orphan' rst files in the top level
directory. This is not the correct long-term thing to do with these
files -- my suggestions for most of them are in this thread:
https://lore.kernel.org/qemu-devel/CAFEAcA_ff6bRythvzJWs0McUSz3=2=1=hV9wX_BTv00jPfSHsw@mail.gmail.com/
-- but for the purposes of this series and until somebody
cleans them up properly, this is the minimal necessary change,
because it's patch 2 that I'm really interested in opinions on.
Earlier discussion on one manual vs multiple was partly on IRC
but also in this thread:
https://lore.kernel.org/qemu-devel/CAFEAcA_4wXqGeOgsY2GbY1mk==DCz--j-jhs+OdGQnOHEf+D_A@mail.gmail.com/
Incidentally, historically we did ship some internals documentation
to end users -- the old qemu-tech.texi "translator internals"
ended up in the user manual. The new 'devel' manual is a lot
bigger, of course.
If you don't want to apply this patch and build the docs to see
what the effect is, you can just look at the readthedocs output
to see what one-big-manual looks like:
https://qemu.readthedocs.io/en/latest/
Side note: it would be nice not to have to duplicate the
list of manpages in docs/conf.py and docs/meson.build. I think
if we didn't insist on only installing the manpages that apply
to the configuration we built for (ie if we installed the full
manpage docs the same way we install the full HTML docs
regardless of config) we could do that, by having Sphinx
build the manpages into a manpages/man[178]/ hierarchy and
just having meson.build do an install_subdir() on it. But
for this patchset I've retained the current behaviour.
thanks
-- PMM
Peter Maydell (2):
docs: Mark rst files in the top level directory as orphan
docs: Build and install all the docs in a single manual
docs/conf.py | 37 ++++++++++++++++++++-
docs/cpu-hotplug.rst | 2 ++
docs/devel/conf.py | 15 ---------
docs/index.html.in | 17 ----------
docs/interop/conf.py | 26 ---------------
docs/meson.build | 64 ++++++++++++++----------------------
docs/microvm.rst | 2 ++
docs/pr-manager.rst | 2 ++
docs/specs/conf.py | 16 ---------
docs/system/conf.py | 28 ----------------
docs/tools/conf.py | 33 -------------------
docs/user/conf.py | 15 ---------
docs/virtio-net-failover.rst | 2 ++
docs/virtio-pmem.rst | 1 +
14 files changed, 70 insertions(+), 190 deletions(-)
delete mode 100644 docs/devel/conf.py
delete mode 100644 docs/index.html.in
delete mode 100644 docs/interop/conf.py
delete mode 100644 docs/specs/conf.py
delete mode 100644 docs/system/conf.py
delete mode 100644 docs/tools/conf.py
delete mode 100644 docs/user/conf.py
--
2.20.1
next reply other threads:[~2020-11-09 21:46 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-09 21:44 Peter Maydell [this message]
2020-11-09 21:44 ` [RFC 1/2] docs: Mark rst files in the top level directory as orphan Peter Maydell
2020-11-09 21:44 ` [RFC 2/2] docs: Build and install all the docs in a single manual Peter Maydell
2020-11-10 16:40 ` [RFC 0/2] Build a single Sphinx manual, not five Paolo Bonzini
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=20201109214420.32131-1-peter.maydell@linaro.org \
--to=peter.maydell@linaro.org \
--cc=armbru@redhat.com \
--cc=maxim.cournoyer@gmail.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.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).