Em Fri, 28 Oct 2016 16:12:25 +0300 Jani Nikula <jani.nikula@xxxxxxxxx> escreveu: > On Fri, 28 Oct 2016, Mauro Carvalho Chehab <mchehab@xxxxxxxxxxxxx> wrote: > > Em Fri, 28 Oct 2016 11:07:15 +0200 > > Markus Heiser <markus.heiser@xxxxxxxxxxx> escreveu: > >> My conclusion of this and other discussions on the linux-doc ML is; we > >> have the situation, where *old hats* want to stay with perl, since they > >> are productive with, while sphinx is in the python domain. And there > >> is a need (to answer [2]). > > > > Can't speak for others, but for me, perl is great for writing parsing > > scripts. I can produce reliable scripts in perl on almost no time, > > like the one I wrote today to parse the ABI file. > > I'm pretty good at C and bash scripts, can I use them for random > documentation building things? Maybe elisp too. And I know a guy who > knows Haskell. We can create stuff in them really fast too. > > </snark> > > Long term maintainability of the documentation system as a whole trumps > *any* individual developer benefits. In my books, this was one of the > main reasons to prefer Sphinx over giving the DocBook toolchain life > support. As people mentioned on the RFC for parsing MAINTAINERS, if we're willing to parse it, we should use the already existing script (get_maintainers.pl), instead of using a separate one. The same applies to other databases, like ABI: if we're willing to have a script to parse it, such script should be capable of parsing it for all the needs, and not only documentation. The language here doesn't really matter much, provided that we keep using one of the script languages already used in the Kernel tree at the scripts/ directory. > >> IMO, the sphinx kernel-cmd directive [1] is the gate in between sphinx's > >> python and the perl domains. > > > > I agree. > > No, it's a gate between Sphinx and any non-generic, hacky, random tool > or script people think will solve the problem right at the front of > their noses. That gate should be closed and bolted shut. > > Long term, any extensions we use or develop should be generic enough to > be upstreamable to Sphinx. Sphinx may accept something like kernel-cmd (with some other name, of course), but will never accept an extension specifically designed to solve a Kernel documentation issue, like parsing the Linux ABI or MAINTAINERS files and kerneldoc.py, as this doesn't make sense for other projects. That's by the way why I think we should stick with a generic solution, instead of having to develop custom-made ones for every documentation needs. > > It is up to Jon to decide that. Maybe he wants to get some feedback > > about that on KS next week. > > Too bad I won't be there. Don't overwhelm him. ;) :-) Thanks, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
