[Qt-creator] Recommendations for 3rd-party QCH file installation folder for easy discovery?

Eike Ziller 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.

Br, Eike

> On Nov 21, 2016, at 21:40, Friedrich W. H. Kossebau <kossebau at kde.org> wrote:
> Hi,
> 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
> 	/usr/share/doc/packages/qt5/*.qch
> So far I would have guessed
> 	/usr/share/doc/$lib/$lib.qch
> 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
> 	/usr/share/doc/qch
> 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?
> Background:
> 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 
> ones.
> 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!
> Cheers
> Friedrich
> _______________________________________________
> Qt-creator mailing list
> Qt-creator at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/qt-creator

Eike Ziller
Principal Software Engineer

The Qt Company GmbH
Rudower Chaussee 13
D-12489 Berlin
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 mailing list