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@kde.org A/c: kde-frameworks-devel@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@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
