T10112: KDEInstallDirs on Mac

[René J.V. Bertin]

rjvbb created this task.
rjvbb added a project: Build System.

TASK DESCRIPTION
  (I hope this is the better place to discuss something that should be done than a WIP diff review...)
  
  There is a discrepancy under the Mac's OS (and unpatched Qt) between the install locations expected in the code and the install locations used by the build system. The former depend on QStandardPaths for the most part while the latter are hardcoded and depend on the install prefix, assuming an XDG-compatible installation layout.
  
  As a result several developers have come up with workarounds. I myself have developed a patch for QStandardPaths allowing to make it return XDG-compatible locations while still supporting native locations (based on a compile-time decision using preprocessor tokens). This is IMHO the preferred solution for package managers that aim to install everything into a dedicated prefix, like MacPorts, Fink and HomeBrew.
  Others have designed solutions to build standalone app bundles in order to mimick the simple installer-less way of distributing software that is possible on Mac.
  
  I've been thinking of better ways to get things installed where the running software will be looking for it. Initially I thought that a simple wrapper around QStandardPaths could be written so that cmake can simply look up the actual locations. After going over `KDEInstallDirs.cmake` I'm no longer certain if that's feasible, and there might be bootstrap issues I'm not aware of.
  
  I notice though that almost all locations in KDEInstallDirs are based on the `DATAROOTDIR` path. Indeed, a quick test with the patched DrKonqi (from D4929 <https://phabricator.kde.org/D4929>) and
  
    if (WIN32)
        _define_relative(DATAROOTDIR BINDIR "data"
            "read-only architecture-independent data root"
            SHARE_INSTALL_PREFIX)
    elseif(APPLE AND NOT APPLE_FORCE_INSTALL_PREFIX)
        _define_absolute(DATAROOTDIR "/Library/Application Support"
            "read-only architecture-independent data root")
    else()
        _define_absolute(DATAROOTDIR "share"
            "read-only architecture-independent data root"
            SHARE_INSTALL_PREFIX)
    endif()
  
  gave an install that worked just as well as with my patched Qt and `APPLE_FORCE_INSTALL_PREFIX=ON` or `APPLE_FORCE_INSTALL_PREFIX=OFF`. (APPLE_FORCE_INSTALL_PREFIX could also be called APPLE_FORCE_UNIX_DIRS or even APPLE_FORCE_UNIX_STANDARDS as a generic switch usable elsewhere too).
  
  There are a few variables though for which I don't know if this is the right thing (and I might be missing others):
  
  - KDE_INSTALL_APPDIR: this is one where querying QStandardPaths would give an undesirable result (/Applications). But in general this might have to be kept at $SHARE_INSTALL_PREFIX/applications so that any non-KDE5 XDG-compliant software the user might have installed in $PREFIX will be able to interact as expected with KDE software
  - KDE_INSTALL_MANDIR: Apple manpages are installed in standard Unix locations
  - KDE_INSTALL_DBUS* : these are presumable used by KDE AND the D-Bus daemon which is typically installed through MacPorts, Fink or HomeBrew (with $PREFIX one of /opt/local, /sw or /usr/local).
  
  Additional interrogation:
  
  - Can we set `DATAROOTDIR=/Library/Application Support/KDE` so that everything remains nicely bundled? I notice that Qt tend to use `/Library/Application Support/QtProject` for its stuff but can we be certain that the extra path component won't break any lookups?
  
  I'd like to address this so that it becomes possible to do quick builds and installs KDE projects against a stock Qt on Mac in a way that's as similar as possible to how it's done on other Unix versions. It could be simpler than I thought but I'd need some feedback to avoid introducing regressions or cause too much breakage of the standalone-appbundle approaches designed by others (setting `APPLE_FORCE_INSTALL_PREFIX=ON` should ensure that?).

TASK DETAIL
  https://phabricator.kde.org/T10112

To: rjvbb
Cc: #kde_applications, #frameworks, #build_system, rjvbb
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-buildsystem/attachments/20181123/d2321308/attachment.html>