This cmake macro converts docbook to man pages. It depends on kdoctools though, so it creates an unwanted dependency, for low-level frameworks.
Do we have to use docbook as the source for man pages? I presume this was done to ease translations... but I wonder, how other projects outside KDE handle this? Surely man pages can be translated directly, provided the correct scripting around gettext? To make clear what we're talking about: checkXML/man-checkXML.1.docbook kbuildsycoca5/man-kbuildsycoca5.8.docbook kconfig_compiler/man-kconfig_compiler.1.docbook kcookiejar4/man-kcookiejar4.8.docbook kde5-config/man-kde5-config.1.docbook kded5/man-kded5.8.docbook kdeinit5/man-kdeinit5.8.docbook kdeoptions/man-kdeoptions.7.docbook kjscmd/man-kjscmd.1.docbook kjs/man-kjs.1.docbook kross/man-kross.1.docbook makekdewidgets/man-makekdewidgets.1.docbook meinproc4/man-meinproc4.8.docbook preparetips/man-preparetips.1.docbook qtoptions/man-qtoptions.7.docbook This is all about man pages, not about docbook->html for user documentation in khelpcenter. I tried looking into other source packages (for user-facing binaries, not libs which usually have english-only man pages anyway), but lame-3.98.4 has an english-only man page too. Looking at Qt's tools for inspiration: I see no man pages for uic, moc, etc. Hmm. And the man-pages-fr package has very very little binaries: only ldd, and time in man1. I wonder if there's really a point in a KDE solution for translated man pages, when nobody else is doing it... There's of course one solution to keep the current docbook sources: moving them all into the (future) kdoctools framework. Not very modular, but solves the dependency issue. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Sponsored by BlueSystems and KDAB to work on KDE Frameworks _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
