Re: Dropping python 2.7 support in gtk-doc (requiring python 3.X)

[Stefan Sauer <ensonic hora-obscura de>]

On 03/30/2018 02:28 PM, David Nečas wrote:
> On Fri, Mar 30, 2018 at 01:24:06PM +0200, Stefan Sauer wrote:
> > To also give some extra motivation - Since a few month I am working on
> > gtkdoc-mkhtml which is a pure python drop-in replacement for
> > gtkdoc-mkhtml+gtkdoc-fixxref. This is not using docbook xslt anymore and
> > it won't shell out to tools to do syntax highlighting.
> Will the possibility to use docbook xslt disappear?  Or will the new
> tool somehow emulate it completely?  What will happen to ‘content files’
> written in docbook?
My plan is to make it a configure option (like we had 'no-tmpl'
previously). This way people can select which toolchain they prefer.
Let me go through why I started to work on this:
* https://bugzilla.gnome.org/show_bug.cgi?id=785139 - I've reported this
upstream (docbook xslt) and there is nothing happening
* the docbook xslt is slow and it is unlikely that either the
stylesheets nor libsxlt will get dramatically faster. For the later it
is unlikely that it will ever using multiple threads.
* the dependencies don't make the tool very portable
(https://bugzilla.gnome.org/show_bug.cgi?id=788911)

The new tool mkhtml2 reads docbook files and converts them to html (this
includes any xml that is part of it, that is also 'content files'). I
also creates the devhelp2 files. There is no more need for fixxref as it
uses the fixxref module to read the dependent devehelp files to resolve
the links. The syntax highlighting is doe though pygments and I am
tempted to also do this in fixxref (so no more shelling out to vim or
source-highlight).

The new tool is not feature complete yet and to be honest it won't to
100% doing the same as the docbook xslt toolchain. E.g. I won't output a
version footer since e.g. distros complained that this makes packages
less deterministic. On the other hand so far the output looks almost
identical and as long as there is a easy rendering, we can add support
for more tags. The tool will log warnings for unsupported tags and I am
still working on adding more coverage. I am close to test this with
various gnome libraries to see what is most often missing.

The good news is that the tool is ~4 times faster and there is potential
to make it even faster.
> I do not understand.

I hope this clarifies. I am grateful for the patches you wrote on the
perl codebase. I am sorry if there where issues with the new releaes for
your project. Please let me know if you have concerns here.

Happy Easter,
Stefan
> Yeti
>
> _______________________________________________
> gtk-doc-list mailing list
> gtk-doc-list gnome org
> https://mail.gnome.org/mailman/listinfo/gtk-doc-list