D7706: Use runtime install prefix instead of compile time install prefix.

[Ralf Habacker]

habacker added a comment.


  > If all you need is <APPDIR>, you can use QCoreApplication::applicationDirPath().
  
  Did a further look into this stuff and found https://cgit.kde.org/kinit.git/commit/src/kdeinit/kinit_win.cpp?id=6b0ddac715475d7ed36a15f180c755f0f978b7cf. In KDE times there were KStandardDirs::installPath("kdedir") which returns the runtime install prefix. Is a comparable method available in KF5 ?
  
  From your initial reference to QStandardPaths I assume that an universal solution at the time KStandardDirs::installPath("kdedir")  has been ported to QStandardPaths  was something  like adding QStandardPaths::InstallLocation, but seems to be to late now. (TODO for Qt6 ?)
  
  Searching my incomplete KF5 sources for CMAKE_INSTALL_PREFIX show several references to the runtime install prefix (there may be more references)
  
  find -name '*.cpp' -exec grep -Hn CMAKE_INSTALL_PREFIX {} \;
  ./kconfig/src/kconf_update/kconf_update.cpp:766:            path = CMAKE_INSTALL_PREFIX "/" LIB_INSTALL_DIR "/kconf_update_bin/" + script;
  ./kdelibs4support/src/kdecore/kstandarddirs.cpp:370:        return QFile::decodeName(CMAKE_INSTALL_PREFIX "/") + relPath;
  ./kdelibs4support/src/kdecore/kstandarddirs.cpp:1196:            typeInstallPath = QFile::decodeName(CMAKE_INSTALL_PREFIX "/") + QLatin1String("share/applications/");
  ./kdelibs4support/kde-config.cpp:88:        printResult(QFile::decodeName(CMAKE_INSTALL_PREFIX));
  ./kdelibs4support/autotests/kstandarddirstest.cpp:52:    if (kconfig_compilerLocation.startsWith(CMAKE_INSTALL_PREFIX)) {
  ./kdelibs4support/autotests/kstandarddirstest.cpp:141:    return QFile::exists(CMAKE_INSTALL_PREFIX "/bin/kf5-config");
  ./kdelibs4support/autotests/kstandarddirstest.cpp:441:    const QString kdeDataApps = KStandardDirs::realPath(CMAKE_INSTALL_PREFIX "/share/applications/");
  ./kdelibs4support/autotests/kstandarddirstest.cpp:484:    const QString kdeDataApps = KStandardDirs::realPath(CMAKE_INSTALL_PREFIX "/share/applications/");
  ./sonnet/src/plugins/aspell/aspellclient.cpp:36:    // A generated config-aspell.h (or config-kspell.h, if shared) should be added then, to define CMAKE_INSTALL_PREFIX
  ./sonnet/src/plugins/aspell/aspellclient.cpp:37:    return QLatin1String(CMAKE_INSTALL_PREFIX  ASPELL_DATA_ROOT);
  ./kinit/src/kdeinit/kinit.cpp:631:                        CMAKE_INSTALL_PREFIX "/" LIB_INSTALL_DIR "/");
  ./kinit/src/kdeinit/kinit.cpp:1541:    QString path = QFile::decodeName(CMAKE_INSTALL_PREFIX "/" LIB_INSTALL_DIR "/") + lib;
  ./kxmlgui/src/kbugreport.cpp:553:        command = QFile::decodeName(CMAKE_INSTALL_PREFIX "/" KF5_LIBEXEC_INSTALL_DIR "/ksendbugmail");
  
  so I would say yes in KF5 there is the need to have a common function to get the runtime install prefix [1] instead of implementing it on every mentioned place [2].
  
  Using  QCoreApplication::applicationDirPath() falls in category [2] while using QLibraryInfo::location falls into category[1] because from my experience every KF5 application on Windows needs a qt.conf for finding correct pathes. 
  Unfortunally using QLibraryInfo::location on linux would change install prefix which may not work. This indicates that a replacement for KStandardDirs::installPath("kdedir") is required and leads to the question how the function should be named and  where to place it ? In KDE4 times is was in kdecore . For KF5 should it be placed in kcoreaddons ?
  
  This add kcoreaddons as a runtime dependency to all libraries where the above mentioned code locations belongs to.  To avoid the runtime dependency it would be possible to define the function as public inline method in kcoreaddons and to add kcoreaddons as development only dependency tp related libraries. The implementation may use QLibraryInfo::location() on Windows and CMAKE_INSTALL_PREFIX on linux.
  
  Any objections or a better solution ?

REPOSITORY
  R303 KInit

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

To: habacker, dfaure
Cc: dfaure, #frameworks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20170911/b9c164b2/attachment.html>