All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jani Nikula <jani.nikula@linux.intel.com>
To: Markus Heiser <markus.heiser@darmarit.de>,
	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, 09 Nov 2016 13:16:55 +0200	[thread overview]
Message-ID: <8737j0hpi0.fsf@intel.com> (raw)
In-Reply-To: <A4091944-D727-45B5-AC24-FE3B2700298E@darmarit.de>

On Wed, 09 Nov 2016, Markus Heiser <markus.heiser@darmarit.de> wrote:
> 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.;

We're supposed to solve problems, not create new ones.

> 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. 

Well, kernel-include is a hack to make parse-headers.pl work, which is
also a hack that IMHO shouldn't exist...

> 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 --
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-doc" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Jani Nikula, Intel Open Source Technology Center

WARNING: multiple messages have this Message-ID (diff)
From: Jani Nikula <jani.nikula@linux.intel.com>
To: Markus Heiser <markus.heiser@darmarit.de>,
	Josh Triplett <josh@joshtriplett.org>
Cc: Mauro Carvalho Chehab <mchehab@s-opensource.com>,
	Jonathan Corbet <corbet@lwn.net>,
	linux-kernel@vger.kernel.org, linux-media@vger.kernel.org,
	ksummit-discuss@lists.linuxfoundation.org,
	linux-doc@vger.kernel.org
Subject: Re: [Ksummit-discuss] Including images on Sphinx documents
Date: Wed, 09 Nov 2016 13:16:55 +0200	[thread overview]
Message-ID: <8737j0hpi0.fsf@intel.com> (raw)
In-Reply-To: <A4091944-D727-45B5-AC24-FE3B2700298E@darmarit.de>

On Wed, 09 Nov 2016, Markus Heiser <markus.heiser@darmarit.de> wrote:
> 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.;

We're supposed to solve problems, not create new ones.

> 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. 

Well, kernel-include is a hack to make parse-headers.pl work, which is
also a hack that IMHO shouldn't exist...

> 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 --
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-doc" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Jani Nikula, Intel Open Source Technology Center

  reply	other threads:[~2016-11-09 11:16 UTC|newest]

Thread overview: 102+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-07  9:55 [Ksummit-discuss] Including images on Sphinx documents Mauro Carvalho Chehab
2016-11-07  9:55 ` Mauro Carvalho Chehab
2016-11-07 10:53 ` [Ksummit-discuss] " Jani Nikula
2016-11-07 10:53   ` Jani Nikula
2016-11-07 11:46   ` [Ksummit-discuss] " Mauro Carvalho Chehab
2016-11-07 11:46     ` Mauro Carvalho Chehab
2016-11-07 17:05     ` [Ksummit-discuss] " Josh Triplett
2016-11-07 17:05       ` Josh Triplett
2016-11-08 10:50       ` Mauro Carvalho Chehab
2016-11-08 10:50         ` Mauro Carvalho Chehab
2016-11-16 16:03         ` Arnd Bergmann
2016-11-16 16:03           ` Arnd Bergmann
2016-11-16 20:26           ` Mauro Carvalho Chehab
2016-11-16 20:26             ` Mauro Carvalho Chehab
2016-11-17 11:07             ` Arnd Bergmann
2016-11-17 11:07               ` Arnd Bergmann
2016-11-17 11:28               ` Jani Nikula
2016-11-17 11:28                 ` Jani Nikula
2016-11-17 12:39                 ` Mauro Carvalho Chehab
2016-11-17 12:39                   ` Mauro Carvalho Chehab
2016-11-17 14:52               ` Theodore Ts'o
2016-11-17 14:52                 ` Theodore Ts'o
2016-11-17 15:16                 ` Mauro Carvalho Chehab
2016-11-17 15:16                   ` Mauro Carvalho Chehab
2016-11-17 15:28                   ` Johannes Berg
2016-11-17 15:28                     ` Johannes Berg
2016-11-17 16:25                   ` James Bottomley
2016-11-17 16:25                     ` James Bottomley
2016-11-17 15:32               ` Mauro Carvalho Chehab
2016-11-17 15:32                 ` Mauro Carvalho Chehab
2016-11-17 16:02               ` Linus Torvalds
2016-11-17 16:02                 ` Linus Torvalds
2016-11-17 16:04                 ` Linus Torvalds
2016-11-17 16:04                   ` Linus Torvalds
2016-11-18  9:15                 ` Jani Nikula
2016-11-18  9:15                   ` Jani Nikula
2016-11-18 10:23                   ` Daniel Vetter
2016-11-18 10:23                     ` Daniel Vetter
2016-11-19 17:15                 ` Jonathan Corbet
2016-11-19 17:15                   ` Jonathan Corbet
2016-11-19 17:38                   ` Andrew Lunn
2016-11-19 17:38                     ` Andrew Lunn
2016-11-19 17:50                   ` Bart Van Assche
2016-11-19 17:50                     ` Bart Van Assche
2016-11-19 17:55                   ` David Woodhouse
2016-11-19 17:55                     ` David Woodhouse
2016-11-19 18:45                     ` Linus Torvalds
2016-11-19 18:45                       ` Linus Torvalds
2016-11-19 22:59                       ` David Woodhouse
2016-11-19 22:59                         ` David Woodhouse
2016-11-20 14:26                         ` Mauro Carvalho Chehab
2016-11-20 14:26                           ` Mauro Carvalho Chehab
2016-11-19 20:54                   ` Mauro Carvalho Chehab
2016-11-19 20:54                     ` Mauro Carvalho Chehab
2016-11-19 21:09                     ` Linus Torvalds
2016-11-19 21:09                       ` Linus Torvalds
2016-11-21 10:39                   ` Johannes Berg
2016-11-21 10:39                     ` Johannes Berg
2016-11-21 14:06                     ` Mauro Carvalho Chehab
2016-11-21 14:06                       ` Mauro Carvalho Chehab
2016-11-21 15:41                       ` James Bottomley
2016-11-21 15:41                         ` James Bottomley
2016-11-21 15:44                         ` Johannes Berg
2016-11-21 15:44                           ` Johannes Berg
2016-11-21 15:47                           ` Jani Nikula
2016-11-21 15:47                             ` Jani Nikula
2016-11-21 19:48                           ` Mauro Carvalho Chehab
2016-11-21 19:48                             ` Mauro Carvalho Chehab
2016-11-13 21:00     ` Jonathan Corbet
2016-11-13 21:00       ` Jonathan Corbet
2016-11-14 14:16       ` [Ksummit-discuss] " Mauro Carvalho Chehab
2016-11-14 14:16         ` Mauro Carvalho Chehab
2016-11-09 12:27   ` [Ksummit-discuss] " Mauro Carvalho Chehab
2016-11-09 12:27     ` Mauro Carvalho Chehab
2016-11-07 17:01 ` [Ksummit-discuss] " Josh Triplett
2016-11-07 17:01   ` Josh Triplett
2016-11-09  9:22   ` Markus Heiser
2016-11-09  9:22     ` Markus Heiser
2016-11-09 11:16     ` Jani Nikula [this message]
2016-11-09 11:16       ` Jani Nikula
2016-11-09 11:27       ` Mauro Carvalho Chehab
2016-11-09 11:27         ` Mauro Carvalho Chehab
2016-11-09 11:45         ` Jani Nikula
2016-11-09 11:45           ` Jani Nikula
2016-11-09 11:27       ` Markus Heiser
2016-11-09 11:27         ` Markus Heiser
2016-11-09 11:58         ` Jani Nikula
2016-11-09 11:58           ` Jani Nikula
2016-11-09 22:11           ` Markus Heiser
2016-11-09 22:11             ` Markus Heiser
2016-11-10 10:35             ` Jani Nikula
2016-11-10 10:35               ` Jani Nikula
2016-11-11 11:22               ` Jani Nikula
2016-11-11 11:22                 ` Jani Nikula
2016-11-11 11:45                 ` Markus Heiser
2016-11-11 11:45                   ` Markus Heiser
2016-11-11  9:34           ` Mauro Carvalho Chehab
2016-11-11  9:34             ` Mauro Carvalho Chehab
2016-11-13 19:52 ` Jonathan Corbet
2016-11-13 19:52   ` Jonathan Corbet
2016-11-14 13:30   ` [Ksummit-discuss] " Mauro Carvalho Chehab
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=8737j0hpi0.fsf@intel.com \
    --to=jani.nikula@linux.intel.com \
    --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=markus.heiser@darmarit.de \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.