link qch tags together
Open, Needs TriagePublic

Description

attica builds qt tags files and puts them in libkf5attica-doc
knewstuff builds qt tags and puts them in libkf5newstuff-dev
but there's a new feature where newstuff tags should link to attica tags so a build-dep needs to knewstuff to build-dep on libkf5attica-doc

add a compile time check that all these are satisfied

jriddell created this task.Aug 2 2019, 9:25 AM
sitter added a subscriber: sitter.Aug 2 2019, 9:35 AM
[11:29] <sitter> I do rather think that this also needs a fix in ECM, no?
[11:29] <JonathanRiddell-> sitter: ecm does complain about it, what more should it do?
[11:30] <sitter> the complaint should be a feature_info I would think
[11:30] <sitter> 02:22:21 -- The following features have been enabled:
[11:30] <sitter> 02:22:21 
[11:30] <sitter> 02:22:21  * QCH, API documentation in QCH format (for e.g. Qt Assistant, Qt Creator & KDevelop)
[11:30] <sitter> ther should also be a feature QCH-Qt5 linkage or somesuch
[11:30] <JonathanRiddell-> mm right
[11:31] <DavidRedondo-M> frinring
[11:31] <DavidRedondo-M> one could also change the code not to skip silently, but make noise or even fail
[11:31] <DavidRedondo-M> at the time when I wokred on that I did not want to be too aggressive here, to not have people run into lots of issues before they could see something...
[11:31] <DavidRedondo-M> yesterday
[11:31] <DavidRedondo-M> I would agree that a warning would be good
[11:33] --> dharman (~dharman@93-42-171-52.ip87.fastwebnet.it) has joined this channel.
[11:34] <sitter> JonathanRiddell-: in fact it seems our tooling nowadays ignores Warnings altogether, supposedly because the cmake files are often in a horrible state and raise warnings when they should raise author_warning
[11:34] <sitter> that is something we could revisit
[11:34] <sitter> obviously if we do we also need to deal with that very problem that often times people use WARNING when they should have used AUTHOR_WARNING ^^
kossebau added a subscriber: kossebau.EditedAug 2 2019, 11:14 AM

Small feedback/info from my discussions with opensuse packagers (who sadly still need to finish execution/implementation), which might help on designing solutions:

the tags files (which are a doxygen specific format) could be roughly compared to headers of C++ libraries, being a database with all info needed when generating a new documentation library which should have links into that other library (as well as include data like that for classes inherited) which the tags file describes. The actual documentation file (like a QCH file) is not used/needed, all info is in that tags files.

At runtime (i.e. when using QCH files with Qt Assistant, Qt Creator or KDevelop), the tags files are not futher needed.

So, ignoring the amount pf packages we are creating, the tags file could be split off into some lib-doc-devel package, and would be only installed for building QCH files (or other formats which doxygen supports).
Bundling the tags files with the QCH files has this disadvantage on build servers:
QCH files are very large, and for libs linking publically against a lot of other libraries, thus also needing for their QCH file generation all the tags files of the other libs, would result in deploying lots of big packages to that build.

Similar also for the Qt documentation. The openSUSE packagers have split off the tags files from the QCH files into doc-devel packages with the Qt packages already. Though also adding the QDoc index files to the same doc-devel, which I would not have done, but well... (index files are for qdoc what tags fies are for doxygen, a database needed only for "linking" documenation "libraries").

How the packages are split is generally done by the Debian packagers and we just copy them.

Seems like it would be fine to put the .tags files into the -dev files along with headers and then they'd magically be picked up at build time.

Putting in normal -dev files is also an option, sure.

davidre added a subscriber: davidre.Aug 2 2019, 2:05 PM

What does this error mean @kossebau ?
'-- No such target KF5PulseAudioQt_QCH when calling ecm_install_qch_export().

  • No target exported for KF5PulseAudioQt_QCH.

'

We are getting this on pulseaudio-qt itself.

Or on knewstuff I'm seeing:
'-- No such target Qt5DBus_QCH defined when calling ecm_add_qch(), ignored.'

What does this error mean @kossebau ?
'-- No such target KF5PulseAudioQt_QCH when calling ecm_install_qch_export().

  • No target exported for KF5PulseAudioQt_QCH. '

    We are getting this on pulseaudio-qt itself.

That is because ecm_install_qch_export is called there before the respective target has been defined, which only happens later once add_subdirectory(src) is reached. That needs fixing in their cmake code.

See https://phabricator.kde.org/source/pulseaudio-qt/browse/master/CMakeLists.txt$49 ff. and https://phabricator.kde.org/source/pulseaudio-qt/browse/master/src/CMakeLists.txt$77 ff.

Or on knewstuff I'm seeing:
'-- No such target Qt5DBus_QCH defined when calling ecm_add_qch(), ignored.'

The latter is due to a bug with no tags file having been provided for Qt5DBus by Qt build system, but that got fixed recently for Qt 5.13+: https://bugreports.qt.io/browse/QTBUG-60933

thanks much!

seems good but needs to update to newer qt for the qt bits and to get into debian

jriddell edited projects, added Neon2Debian; removed Neon.Sep 12 2019, 10:31 AM

I have done all the work in debian upstream repos - however, due to it triggering NEW they decided to wait for the next release to apply otherwise it would add a significant delay to an already delayed qt release.