[Differential] [Commented On] D2854: New: ECMAddQch, for generating qch & doxygen tag files

kossebau (Friedrich W. H. Kossebau) noreply at phabricator.kde.org
Tue Dec 6 15:13:09 UTC 2016


kossebau added inline comments.

INLINE COMMENTS

> shumski wrote in KDEInstallDirs.cmake:534
> Hm, i guess i haven't checked KDEInstallDirs in a while. Somehow i remember KDE_INSTALL_USE_QT_SYS_PATHS was only activated by default if CMAKE_INSTALL_PREFIX was /usr.
> 
> Ok, so the non-recognition part should not happen that often -> I'm assuming qch files are looked up as QLibraryInfo::DocumentationPath (so, QT_INSTALL_DOCS)  + *qch.
> 
> So with your path, they will not be found (yeah with different prefix they aren0t still found, but with qch/ subdir user needs one additional envar for KF5 qch's - imagine you need to export QT_PLUGIN_PATH for Qt plugins, and one more path for KF5 plugins).
> I don't see a reason to append qch subdir to installation location -> as if you're intentionally hiding those files ;-)

Any chance you perhaps misread the code? Because what you say does not match what should happen at least by what I intended by the code (and what it does on testing) :)

The qch/ subdir is used with the non-QT_INSTALL_DOCS installation directory. So `_define_relative(QTQCHDIR DATAROOTDIR "doc/qch")` would be e.g. "/usr/share/doc/qch" when installing to prefix /usr. Both this and "/usr/share/doc" will never result in Qt Assistant automatically adding the QCH file to the default help file collection. This only happens when installing directly into QT_INSTALL_DOCS (undocumented feature, but stable for some time :) ).

In the branch which sets up QTQCHDIR to be the Qt system dir, `_define_absolute(QTQCHDIR ${qt_docs_dir})` will result in QTQCHDIR being equal to QT_INSTALL_DOCS. No /qch subdir here.

REPOSITORY
  R240 Extra CMake Modules

REVISION DETAIL
  https://phabricator.kde.org/D2854

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: kossebau, staniek, #frameworks
Cc: shumski, kfunk, staniek, winterz, ochurlaud, #kdevelop
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20161206/5f774d7e/attachment-0001.html>


More information about the Kde-frameworks-devel mailing list