From: Mauro Carvalho Chehab <mchehab@infradead.org>
To: Markus Heiser <markus.heiser@darmarit.de>
Cc: Jani Nikula <jani.nikula@intel.com>,
Mauro Carvalho Chehab <mchehab@s-opensource.com>,
Hans Verkuil <hverkuil@xs4all.nl>,
Linux Media Mailing List <linux-media@vger.kernel.org>,
Jonathan Corbet <corbet@lwn.net>,
linux-doc@vger.kernel.org, Daniel Vetter <daniel.vetter@ffwll.ch>
Subject: Re: parts of media docs sphinx re-building every time?
Date: Wed, 10 Aug 2016 07:11:50 -0300 [thread overview]
Message-ID: <20160810071150.61d3adcf@vela.lan> (raw)
In-Reply-To: <63B4006C-EF1F-4291-B235-A562EA53DFA6@darmarit.de>
Em Wed, 10 Aug 2016 11:58:48 +0200
Markus Heiser <markus.heiser@darmarit.de> escreveu:
> Am 10.08.2016 um 11:22 schrieb Mauro Carvalho Chehab <mchehab@infradead.org>:
>
> > Em Wed, 10 Aug 2016 12:15:34 +0300
> > Jani Nikula <jani.nikula@intel.com> escreveu:
> >
> >> On Mon, 08 Aug 2016, Markus Heiser <markus.heiser@darmarit.de> wrote:
> >>> Hi Jani,
> >>>
> >>> Am 08.08.2016 um 17:37 schrieb Jani Nikula <jani.nikula@intel.com>:
> >>>
> >>>>
> >>>> Hi Mauro & co -
> >>>>
> >>>> I just noticed running 'make htmldocs' rebuilds parts of media docs
> >>>> every time on repeated runs. This shouldn't happen. Please investigate.
> >>>>
> >>>> I wonder if it's related to Documentation/media/Makefile... which I have
> >>>> to say I am not impressed by. I was really hoping we could build all the
> >>>> documentation by standalone sphinx-build invocation too, relying only on
> >>>> the conf.py so that e.g. Read the Docs can build the docs. Part of that
> >>>> motivation was to keep the build clean in makefiles, and handing the
> >>>> dependency tracking completely to Sphinx.
> >>>>
> >>>> I believe what's in Documentation/media/Makefile,
> >>>> Documentation/sphinx/parse-headers.pl, and
> >>>> Documentation/sphinx/kernel_include.py could be replaced by a Sphinx
> >>>> extension looking at the sources directly.
> >>>
> >>> Yes, parse-headers.pl, kernel_include.py and media/Makefile are needed
> >>> for one feature ... not very straight forward.
> >>>
> >>> If it makes sense to migrate the perl scripts functionality to a
> >>> Sphinx extension, may I can help ... depends on what Mauro thinks.
> >>>
> >>> BTW: parse-headers.pl is not the only perl script I like to migrate to py ;)
> >>
> >> If I understand the need of all of this right, I think the cleanest and
> >> fastest short term measure would be to make the kernel-include directive
> >> extension do the same thing as the kernel-doc directive does: call the
> >> perl script from the directive.
> >>
> >> This lets you get rid of Documentation/media/Makefile and you don't have
> >> to copy-paste all of Include.run method into kernel_include.py. You can
> >> also get rid of specifying environment variables in rst files and
> >> parsing them in the extension. We can get rid of the problematic
> >> intermediate rst files. This design has been proven with the kernel-doc
> >> extension and script already. It's much simpler.
> >
> > Works for me. If someone comes with such patch, I'll happily ack it.
> >
> > Cheers,
> > Mauro
>
> Hi Jani & Mauro,
>
> I will give it a try ... but currently I'am working in some other tasks.
> I think next week I will find some time to implement.
Good enough to me, Thanks for looking into that!
Cheers,
Mauro
next prev parent reply other threads:[~2016-08-10 18:51 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <8760rbp8zh.fsf@intel.com>
2016-08-08 16:07 ` parts of media docs sphinx re-building every time? Markus Heiser
2016-08-08 17:26 ` Mauro Carvalho Chehab
2016-08-10 7:46 ` Jani Nikula
2016-08-10 9:04 ` Mauro Carvalho Chehab
2016-08-10 9:15 ` Jani Nikula
2016-08-10 9:22 ` Mauro Carvalho Chehab
2016-08-10 9:58 ` Markus Heiser
2016-08-10 10:11 ` Mauro Carvalho Chehab [this message]
2016-08-10 12:24 ` Daniel Vetter
2016-08-10 7:42 ` Jani Nikula
2016-08-10 8:23 ` Mauro Carvalho Chehab
2016-08-10 8:52 ` Mauro Carvalho Chehab
2016-08-10 8:47 ` Mauro Carvalho Chehab
2016-08-10 9:23 ` Jani Nikula
2016-08-10 13:46 ` Jonathan Corbet
2016-08-10 14:16 ` Markus Heiser
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=20160810071150.61d3adcf@vela.lan \
--to=mchehab@infradead.org \
--cc=corbet@lwn.net \
--cc=daniel.vetter@ffwll.ch \
--cc=hverkuil@xs4all.nl \
--cc=jani.nikula@intel.com \
--cc=linux-doc@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox