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@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
