[KDE/Mac] Building Guide? ;)
René J.V. Bertin
rjvbertin at gmail.com
Mon Oct 5 09:11:56 UTC 2015
On Monday October 05 2015 07:55:27 Marko Käning wrote:
> > On a side question, is there any list of KF5 packages that doesn't make sense to build on OS X ?
> for KF5 version 5.13 I was able to successfully build all frameworks - omitting (Modem|Network)ManagerQt.
> However, on OSX not all are really usable. You may want to check out comments regarding that on , which
> mentions BluezQt, (Modem|Network)ManagerQt, KCrash (!), KPty, Baloo, KDESu and KGlobalAccel.
> 1) That KCrash is listed in there is quite irritating for me… ( @ Ian !!!??? )
KDESu also be functional, at least where it's used to launch helper applications with elevated permissions.
> 2) I am also not sure whether KGlobalAccel is actually not used/usable on OSX.
I'm pretty sure it's KDE4 equivalent is used and useful. Why would we want NOT to be able to change or add global shortcuts, but only app-specific shortcuts?
> Could we build KF5 apps on Apple OS X around a KF5 framework
> and a Qt5 framework (in the Apple sense of "framework")? Inside
> the KF5 framework there could be an analog of /usr/local/share...
Basically, I think Digia would already have implemented that if there were any advantage to it. As it is, both Qt5 and KF5 are conceived with a modularity principle in mind, in which you only link against the things you need.
It might be possible to make a "meta" framework bundle that has "sub" frameworks, but I don't think that has any advantages unless the App Store has a provision for allowing application suites to share common framework bundles in some sort of common sandbox. But as I've said before, everything related to hypothetical KF5 App Store submissions is currently science fiction in my eyes almost like controlled nuclear fusion and FTL travel. We should be focusing on simpler things.
Jeremy: try this for your rpath issue:
* configure with -no-rpath and use this patch:
diff --git a/qtbase/configure b/qtbase/configure
index 90c811e..cc1c1e7 100755
@@ -5152,8 +5152,19 @@ if [ "$XPLATFORM_MAC" = "yes" ]; then
# auto-detect OpenGL support (es2 = OpenGL ES 2.0 or higher)
+ if [ "$QT_QPA_DEFAULT_PLATFORM" = "cocoa" ] || [ "$QT_QPA_DEFAULT_PLATFORM" = "" -a "$XPLATFORM_MAC" = "yes" ]; then
+ # QT_QPA_DEFAULT_PLATFORM is either empty or set by the user, so we have to check
+ # both manually and automatically selected cocoa. It qpa=cocoa, we do NOT want to
+ # use pkg-config to find the OpenGL libraries because it's too likely to find
+ # OpenGL libraries that are not the system frameworks appropriate for cocoa mode.
+ compileTest unix/opengldesktop "OpenGL"
+ compileTestWithPkgConfig gl unix/opengldesktop "OpenGL" OPENGL
if [ "$CFG_OPENGL" = "auto" ] || [ "$CFG_OPENGL" = "yes" ]; then
- if compileTestWithPkgConfig gl unix/opengldesktop "OpenGL" OPENGL; then
+ if doOpenGLTest; then
elif compileTestWithPkgConfig glesv2 unix/opengles2 "OpenGL ES 2.0" OPENGL_ES2; then
@@ -5181,7 +5192,7 @@ elif [ "$CFG_OPENGL" = "es2" ]; then
elif [ "$CFG_OPENGL" = "desktop" ]; then
# Desktop OpenGL support
- compileTestWithPkgConfig gl unix/opengldesktop "OpenGL" OPENGL
if [ $? != "0" ]; then
echo "The OpenGL functionality test failed!"
echo " You might need to modify the include and library search paths by editing"
@@ -6246,6 +6257,9 @@ else
if [ "$CFG_RPATH" = "yes" ]; then
+elif [ "$XPLATFORM_MAC" = "yes" ]; then
+ # store the absolute (= full) path in shared library install_names
+ QMAKE_CONFIG="$QMAKE_CONFIG absolute_library_soname"
if [ '!' -z "$W_FLAGS" ]; then
The last bit re: absolute_library_soname is what went missing from Qt's configure (bug that should be addressed in the next release).
(I've left in the OpenGL bit because I presume you too have pkgconfig in your path, and maybe even OpenGL/X11 stuff installed that should *not* be found when building for OS X)
More information about the kde-mac