Poor W32-meson compatibility

Submitted by LRN @ruslanizhb

Link to original bug (#788911)

Description

Since 1.26, gtk-doc got a new, shiny Python rewrite, and i hoped that this would fix meson integration[1] when running on Windows.

I was wrong.

The crux of the matter is the fact that gtk-doc remains very *nix-y due to the tools that it uses (xsltproc & docbook, vim). For example, it must ensure that XML_CATALOG_FILES is a :-separated list of *nix paths, not a ;-separated list of W32 paths, otherwise xsltproc[2] will fail to find the stylesheets (or whatever it is that it looks for in the filesystem). Vim also requires some state that doesn't seem[3] to survive the MSYS(bash)->W32 (python-meson+python-gtk-doc)->MSYS(vim) trip, and fails to do the highlighting that it is supposed to do (so far i was unable to figure out exactly which environmental variable breaks it).

This means that the W32/MSYS separation line should be drawn between meson and gtk-doc (whereas previously it didn't exist - gtk-doc was invoked by autotools & make, both of which were on MSYS side of things already, same as gtk-doc itself). That might be doable (though i doubt that meson devs will happily accept the necessary patches). Obviously, by remaining *nix-y gtk-doc will [likely] remain unusable for MSVC users (not that i care, you understand).

What is the official Windows compatibility policy for gtk-doc? And for Gnome in general, as far as documentation goes.

[1] meson integration matters because gtk4 generation of the stack already lost autotools support, and i fear that gtk3 generation of the stack is next in line

[2] MSYS-xsltproc is used in favour of MinGW-xsltproc because otherwise various *nix-y paths widely hard-coded into stylesheets don't work

[3] Note that my MSYS2 environment is slightly unusual (also, quite old), so it's possible that official MSYS2 works around this somehow