From: Jani Nikula <jani.nikula@linux.intel.com> To: Markus Heiser <markus.heiser@darmarit.de> 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:58:12 +0200 [thread overview] Message-ID: <87shr0g90r.fsf@intel.com> (raw) In-Reply-To: <DC27B5F7-D69E-4F22-B184-B7B029392959@darmarit.de> On Wed, 09 Nov 2016, Markus Heiser <markus.heiser@darmarit.de> wrote: > Am 09.11.2016 um 12:16 schrieb Jani Nikula <jani.nikula@linux.intel.com>: >>> 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. > > ... new ones? ... Handle in-tree builds without copying. Make dependency analysis with source rst and "intermediate" rst work. Make sure your copying gets the timestamps right. Make Sphinx dependency analysis look at the right copies depending on in-tree vs. out-of-tree. Generally make sure it doesn't confuse Sphinx's own dependency analysis. The stuff I didn't think of. Sure, it's all supposed to be basic Makefile stuff, but don't make the mistake of thinking just one invocation of 'cp' will solve all the problems. It all adds to the complexity we were trying to avoid when dumping DocBook. It adds to the complexity of debugging stuff. (And hey, there's still the one rebuilding-stuff-for-no-reason issue open.) If you want to keep the documentation build sane, try to avoid the Makefile preprocessing. And same old story, if you fix this for real, even if as a Sphinx extension, *other* people than kernel developers will be interested, and *we* don't have to do so much ourselves. BR, Jani. > >>> 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 -- -- 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> Cc: Josh Triplett <josh@joshtriplett.org>, 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:58:12 +0200 [thread overview] Message-ID: <87shr0g90r.fsf@intel.com> (raw) In-Reply-To: <DC27B5F7-D69E-4F22-B184-B7B029392959@darmarit.de> On Wed, 09 Nov 2016, Markus Heiser <markus.heiser@darmarit.de> wrote: > Am 09.11.2016 um 12:16 schrieb Jani Nikula <jani.nikula@linux.intel.com>: >>> 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. > > ... new ones? ... Handle in-tree builds without copying. Make dependency analysis with source rst and "intermediate" rst work. Make sure your copying gets the timestamps right. Make Sphinx dependency analysis look at the right copies depending on in-tree vs. out-of-tree. Generally make sure it doesn't confuse Sphinx's own dependency analysis. The stuff I didn't think of. Sure, it's all supposed to be basic Makefile stuff, but don't make the mistake of thinking just one invocation of 'cp' will solve all the problems. It all adds to the complexity we were trying to avoid when dumping DocBook. It adds to the complexity of debugging stuff. (And hey, there's still the one rebuilding-stuff-for-no-reason issue open.) If you want to keep the documentation build sane, try to avoid the Makefile preprocessing. And same old story, if you fix this for real, even if as a Sphinx extension, *other* people than kernel developers will be interested, and *we* don't have to do so much ourselves. BR, Jani. > >>> 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 -- -- Jani Nikula, Intel Open Source Technology Center
next prev parent reply other threads:[~2016-11-09 11:58 UTC|newest] Thread overview: 103+ 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: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 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 [this message] 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=87shr0g90r.fsf@intel.com \ --to=jani.nikula@linux.intel.com \ --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: linkBe 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.