kjsembed tier (Re: Build failed in Jenkins: kjsembed_master_qt5 #27)

Luigi Toscano luigi.toscano at tiscali.it
Sat Mar 1 22:18:25 UTC 2014


David Faure wrote:
> On Saturday 01 March 2014 12:49:02 Aurélien Gâteau wrote:
>> If I am not mistaken, KJSEmbed depends on KDocTools because it uses
>> kdoctools_create_manpage. Would it be an option to generate the man page
>> without KDocTools. It's a bit sad to bump it from tier 2 to tier 3 just
>> because of this.
> 
> Hmm, especially for the contents of that man page (which could all be in the 
> --help output).
> 
> I would either:
> 1) get rid of the man page and improve --help instead
> or
> 2) put the generated kjscmd5.1 file into git, with a shell-script that calls 
> kdoctools for updating it when modifying the docbook. 
> 
In this case I agree with 1): the command is not really user-facing, so even
if we lose the man page (and the translated versions) it's not really a big
issue. At most we could use something like help2man, but for sure the static
version could go easily out of sync.
Generally speaking, it's possible to generate manpages from docbook, but then
our extensions (entities) should be removed, I wouldn't try to avoid that if
it's not really needed.

I have a question regarding this specific case, kjsembed: is this pushing it
down really important? Which means: is it still used, or should it be moved to
the "depracted" area? I tried to check from lxr and I don't see really big
users (apart the Kross engine).

Ciao
-- 
Luigi


More information about the Kde-frameworks-devel mailing list