Bug 459214

SUMMARY
When an add_executable() binary is cmake-installed on macOS, it ends up copied directly into /Applications/KDE. This is defined by KDEInstallDirs5 and follows the original assumption from 10 years ago, when KDEInstallDirs.cmake was crafted: https://invent.kde.org/frameworks/extra-cmake-modules/-/commit/7289a5515ef107f1d15a4743a63b298337d9a214

Not only this ignores the -DCMAKE_INSTALL_PREFIX, it goes against the paradigm of macOS apps, where additional helper tools typically  provided by add_executable() would be added *inside* the main app bundle itself — see https://developer.apple.com/documentation/bundleresources/placing_content_in_a_bundle for a reference.

 In this context, a library (L) should not be installing its helper tool (T) bundle to /Application. Instead, any Application (A) which depends on library (L) should embed that library's tooling (T) bundles inside its (A's) own bundle.

What it means for the libraries is that bundles should be installed into regular /bin folder, while consuming Application's packaging tooling should copy the binaries accordingly — which, I believe, is the case for Craft.

STEPS TO REPRODUCE
1. Checkout kf5guiaddons
2. run cmake with an added -DCMAKE_INSTALL_PREFIX=/tmp/foo
3. make install

OBSERVED RESULT

(...)
-- Installing: /tmp/foo/debug/mkspecs/modules/qt_KGuiAddons.pri
-- Installing: /tmp/foo/debug/share/qlogging-categories5/kguiaddons.categories
-- Up-to-date: /Applications/KDE/kde-geo-uri-handler.app
-- Up-to-date: /Applications/KDE/kde-geo-uri-handler.app/Contents
(...)

EXPECTED RESULT
kde-geo-uri-handler.app bundle should be installed in /tmp/foo/bin/