kjsembed tier (Re: Build failed in Jenkins: kjsembed_master_qt5 #27)
David Faure
faure at kde.org
Wed Mar 5 07:58:39 UTC 2014
On Saturday 01 March 2014 23:18:25 Luigi Toscano wrote:
> 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).
Yeah I think kross is the main user. Aurelien, the question on "is it really
important to push it down" is for you, you wrote " It's a bit sad to bump it
from tier 2 to tier 3 just because of this." :)
I tend to agree that the current situation (tier3) is good enough so I'm
tempted to just drop the matter (the only thing missing is an explicit
dependency to kdoctools in your graphs, which I would then add).
--
David Faure, faure at kde.org, http://www.davidfaure.fr
Working on KDE, in particular KDE Frameworks 5
More information about the Kde-frameworks-devel
mailing list