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

[tsdgeos at yahoo.es]

‎Sorry for top posting, answering from mobile. 

The script solution has a big problem with l10n, so let's not go there please. Either kill the man page or depend on kdoctools. 

Cheers, 
 Albert

Enviat des del meu telèfon intel·ligent BlackBerry 10.
  Missatge original  
De: Aurélien Gâteau
Enviat: sábado, 1 de marzo de 2014 22:28
Per a: David Faure
Respon a: kde-frameworks-devel at kde.org
A/c: kde-frameworks-devel at kde.org
Tema: Re: kjsembed tier (Re: Build failed in Jenkins: kjsembed_master_qt5 #27)

On Sat, Mar 1, 2014, at 13:06, David Faure wrote:
> On Saturday 01 March 2014 12:49:02 Aurélien Gâteau wrote:
> > On Sat, Mar 1, 2014, at 6:37, David Faure wrote:
> > > Aurélien: you added kdoctools to kjsembed in c5dc9c1d03.
> > 
> > Mmm, which repository are you referring to? I can't find such a revision
> > in the kjsembed repository.
> 
> You didn't set up the git-grafting then :)
> 
> It was actually when it was all in kdelibs.git, so you can find it there
> if you prefer.

Oups, indeed :)
> 
> > Good news: diagrams should now automatically be generated on
> > api.kde.org! I was about to announce it.
> 
> Excellent !
> 
> > KJSEmbed diagram is here:
> > 
> > http://api.kde.org/frameworks-api/frameworks5-apidocs/kjsembed/html/kjsembed
> > -dependencies.html
> > 
> > I had a look at the CMake code in KJSEmbed: it does not link to any
> > target provided by KDocTools, so CMake Graphviz code does not list it as
> > a dependency. 
> 
> Ah, but any find_package(XYZ REQUIRED) makes XYZ a dependency... I didn't
> know the graphviz stuff was based on shared libs only, this indeed misses
> other kinds of dependencies

Yes. I considered at some point not using cmake --graphviz and instead
writing a custom parser to find all calls to find_package(), but was
worried about getting into all the trouble of writing a custom parser
and missing dependencies when/if people start to do create things like
generate the name of the package from a variable.

> (basically deps on cmake files - like ECM, kdoctools or kf5umbrella).

Yes, except frameworks are not allowed to depend on kf5umbrella (and I
assume we do not want to have ECM show up in all diagrams)
> 
> > You can declare the dependency manually. I documented how
> > to do it here:
> > 
> > http://techbase.kde.org/Policies/KDE_Frameworks_Documentation_Policy#.24fram
> > ework.yaml
> > 
> > I can do it if you prefer, but I am interested in finding out whether my
> > doc is understandable :)
> 
> OK I can give it a try - once we decide on the last paragraph:
> 
> > 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. 

I would go for 1), sounds simpler and is more likely to be kept up to
date.

Aurélien
_______________________________________________
Kde-frameworks-devel mailing list
Kde-frameworks-devel at kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel