[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <874m42p35u.fsf@intel.com>
Date: Mon, 24 Oct 2016 11:22:21 +0300
From: Jani Nikula <jani.nikula@...ux.intel.com>
To: Johannes Berg <johannes@...solutions.net>,
Markus Heiser <markus.heiser@...marit.de>,
Jonathan Corbet <corbet@....net>
Cc: Mauro Carvalho Chehab <mchehab@...pensource.com>,
LKML Mailing List <linux-kernel@...r.kernel.org>,
linux-doc@...r.kernel.org
Subject: Re: The downside of math::
On Mon, 24 Oct 2016, Johannes Berg <johannes@...solutions.net> wrote:
> On Sun, 2016-10-23 at 12:58 +0200, Markus Heiser wrote:
>> Further I think we should not generate more (and more) external
>> requirements like e.g. plantuml, Java or reportlab discussed here:
>
> I still disagree, I think we should make it easy to "opt out" for the
> build, but if we're really serious about writing good documentation we
> shouldn't (artificially) limit the tools available.
I'd like to refine: Do not add non-trivial hard dependencies. Do not add
dependencies the lack of which make large parts of generated
documentation useless.
Graceful degradation on unmet dependencies is the key here. Give a build
warn about missing dependencies. Try to do something sensible without
the dependency. For extension directives, all else failing, embed the
raw directive block contents using in the output, possibly accompanied
by a reStructuredText admonition block [1]. For the math and diagram
directives, I think this would work just fine.
BR,
Jani.
[1] http://docutils.sourceforge.net/docs/ref/rst/directives.html#specific-admonitions
--
Jani Nikula, Intel Open Source Technology Center
Powered by blists - more mailing lists