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

[Aurélien Gâteau]

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