[Qt-creator] Recommendations for 3rd-party QCH file installation folder for easy discovery?
Eike.Ziller at qt.io
Tue Nov 22 10:21:24 CET 2016
Hi, I think this discussion belongs to the development@ mailing list, since this is not solely about Qt Creator.
> On Nov 21, 2016, at 21:40, Friedrich W. H. Kossebau <kossebau at kde.org> wrote:
> two questions to anyone working on/with QCH files:
> Q1: what would be a good system path pattern (on *nixoid systems) for Qt-based
> libraries to install their QCH files to?
> Q2: And would/could there be some way to have 3rd-party QCH files
> automatically added to Qt Assistant, Creator & Co. on installation, to spare
> the user the additional manual step?
> For Q1, I see all the Qt ones are on my system at
> So far I would have guessed
> might be a good location. So what patterns do people use for their QCH files
> when delivering to others as part of an install?
> For Q2, having to manually add all QCH files one-by-one to Qt Assistant & Co.
> does not nicely scale if there are a dozen and more 3rd-party QCH files (think
> e.g. all the non-KF5 and KF5 libs created in the KDE community).
> Would it perhaps make sense to have some registration system, so QCH files can
> register themselves somewhere, so Qt Assistant/Creator & other documentation
> viewers know what is present on the system?
> Would some simple sym-linking into some generic dir make sense for a start?
> The /usr/share/doc/packages/qt5 perhaps should be reserved to original Qt
> ones, but perhaps some separate generic dir like
> would work? Or something based on ENV vars, which would avoid hardcoding such
> dirs into Qt Assistant & Co.?
> Actually it would be nice if an installed QCH file would be automatically
> added to Qt Assistant & Co., after all one installed it for a purpose. Are
> there any plans with regard to that?
> I am currently working on adding QCH support to the buildsystem for all the
> libraries of the KDE Frameworks (and other (KDE) library products), for the
> generation of QCH files during builds (https://phabricator.kde.org/D2854).
> This is done with the goals that the API documentation of KDE Frameworks
> libraries can be viewed/used offline with e.g. Qt Assistant, Qt Creator or
> KDevelop, and that packagers/distributors of those libraries automatically
> from the build also have a QCH file matching the very API version of the
> library for packaging (& inclusion into in any package update mechanism).
> The implementation of this support is done by new CMake macros which for now
> make use of the QCH generation feature of doxygen. The macros even support the
> automatic qthelp:// linking to documentation of base libraries, like the Qt
> So once that support works, there will be dozens of QCH files which currently
> would each need manual work by the user to have them added to Qt Assistant &
> Co. Not perfect!
> Qt-creator mailing list
> Qt-creator at qt-project.org
Principal Software Engineer
The Qt Company GmbH
Rudower Chaussee 13
eike.ziller at qt.io
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
More information about the Qt-creator