From: Markus Heiser <markus.heiser@darmarit.de>
To: Josh Triplett <josh@joshtriplett.org>
Cc: ksummit-discuss@lists.linuxfoundation.org,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
Mauro Carvalho Chehab <mchehab@s-opensource.com>,
linux-media@vger.kernel.org
Subject: Re: [Ksummit-discuss] Including images on Sphinx documents
Date: Wed, 9 Nov 2016 10:22:40 +0100 [thread overview]
Message-ID: <A4091944-D727-45B5-AC24-FE3B2700298E@darmarit.de> (raw)
In-Reply-To: <20161107170133.4jdeuqydthbbchaq@x>
Am 07.11.2016 um 18:01 schrieb Josh Triplett <josh@joshtriplett.org>:
> On Mon, Nov 07, 2016 at 07:55:24AM -0200, Mauro Carvalho Chehab wrote:
>> 2) add an Sphinx extension that would internally call ImageMagick and/or
>> inkscape to convert the bitmap;
>
> This seems sensible; Sphinx should directly handle the source format we
> want to use for images/diagrams.
>
>> 3) if possible, add an extension to trick Sphinx for it to consider the
>> output dir as a source dir too.
>
> Or to provide an additional source path and point that at the output
> directory.
The sphinx-build command excepts only one 'sourcedir' argument. All
reST files in this folder (and below) are parsed.
Most (all?) directives which include content like images or literalinclude
except only relative pathnames. Where *relative* means, relative to the
reST file where the directive is used. For security reasons relative
pathnames outside 'sourcepath' are not excepted.
So I vote for :
> 1) copy (or symlink) all rst files to Documentation/output (or to the
> build dir specified via O= directive) and generate the *.pdf there,
> and produce those converted images via Makefile.;
Placing reST files together with the *autogenerated* (intermediate)
content from
* image conversions,
* reST content build from MAINTAINERS,
* reST content build for ABI
* etc.
has the nice side effect, that we can get rid of all theses BUILDDIR
quirks in the Makefile.sphinx
Additional, we can write Makefile targets to build the above listed
intermediate content relative to the $PWD, which is what Linux's
Makefiles usual do (instead of quirking with a BUILDDIR).
E.g. with, we can also get rid of the 'kernel-include' directive
and replace it, with Sphinx's common 'literaliclude' and we do not
need any extensions to include intermediate PDFs or whatever
intermediate content we might want to generate.
IMO placing 'sourcedir' to O= is more sane since this marries the
Linux Makefile concept (relative to $PWD) with the sphinx concept
(in or below 'sourcedir').
-- Markus --
next prev parent reply other threads:[~2016-11-09 9:22 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-07 9:55 Mauro Carvalho Chehab
2016-11-07 10:53 ` Jani Nikula
2016-11-07 11:46 ` Mauro Carvalho Chehab
2016-11-07 17:05 ` Josh Triplett
2016-11-08 10:50 ` Mauro Carvalho Chehab
2016-11-16 16:03 ` Arnd Bergmann
2016-11-16 20:26 ` Mauro Carvalho Chehab
2016-11-17 11:07 ` Arnd Bergmann
2016-11-17 11:28 ` Jani Nikula
2016-11-17 12:39 ` Mauro Carvalho Chehab
2016-11-17 14:52 ` Theodore Ts'o
2016-11-17 15:16 ` Mauro Carvalho Chehab
2016-11-17 15:28 ` Johannes Berg
2016-11-17 16:25 ` James Bottomley
2016-11-17 15:32 ` Mauro Carvalho Chehab
2016-11-17 16:02 ` Linus Torvalds
2016-11-17 16:04 ` Linus Torvalds
2016-11-18 9:15 ` Jani Nikula
2016-11-18 10:23 ` Daniel Vetter
2016-11-19 17:15 ` Jonathan Corbet
2016-11-19 17:38 ` Andrew Lunn
2016-11-19 17:50 ` Bart Van Assche
2016-11-19 17:55 ` David Woodhouse
2016-11-19 18:45 ` Linus Torvalds
2016-11-19 22:59 ` David Woodhouse
2016-11-20 14:26 ` Mauro Carvalho Chehab
2016-11-19 20:54 ` Mauro Carvalho Chehab
2016-11-19 21:09 ` Linus Torvalds
2016-11-21 10:39 ` Johannes Berg
2016-11-21 14:06 ` Mauro Carvalho Chehab
2016-11-21 15:41 ` James Bottomley
2016-11-21 15:44 ` Johannes Berg
2016-11-21 15:47 ` Jani Nikula
2016-11-21 19:48 ` Mauro Carvalho Chehab
2016-11-13 21:00 ` Jonathan Corbet
2016-11-14 14:16 ` Mauro Carvalho Chehab
2016-11-09 12:27 ` Mauro Carvalho Chehab
2016-11-07 17:01 ` Josh Triplett
2016-11-09 9:22 ` Markus Heiser [this message]
2016-11-09 11:16 ` Jani Nikula
2016-11-09 11:27 ` Mauro Carvalho Chehab
2016-11-09 11:45 ` Jani Nikula
2016-11-09 11:27 ` Markus Heiser
2016-11-09 11:58 ` Jani Nikula
2016-11-09 22:11 ` Markus Heiser
2016-11-10 10:35 ` Jani Nikula
2016-11-11 11:22 ` Jani Nikula
2016-11-11 11:45 ` Markus Heiser
2016-11-11 9:34 ` Mauro Carvalho Chehab
2016-11-13 19:52 ` Jonathan Corbet
2016-11-14 13:30 ` 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=A4091944-D727-45B5-AC24-FE3B2700298E@darmarit.de \
--to=markus.heiser@darmarit.de \
--cc=josh@joshtriplett.org \
--cc=ksummit-discuss@lists.linuxfoundation.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=mchehab@s-opensource.com \
/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