[KDE/Mac] Review Request 120437: [OS X] patchset to make QtCurve 1.8.18+ build and work

René J.V. Bertin rjvbertin at gmail.com
Wed Oct 1 16:57:44 UTC 2014



> On Sept. 30, 2014, 9:20 p.m., Marko Käning wrote:
> > How is this supposed to be build on Qt5?
> 
> Yichao Yu wrote:
>     What exactly do you mean?
> 
> Marko Käning wrote:
>     On the CI system I have these options set:
>     ```
>     configureExtraArgs=-DQT5_BUILD=true -DCMAKE_DISABLE_FIND_PACKAGE_X11=TRUE
>     ```
>     but during build the project neither tries to build for Qt5, nor does it stop to search for the X11 libs.
>     
>     What am I missing?
> 
> Marko Käning wrote:
>     What I mean is that I would like to do what René obviously succeeded with: build this project using Qt5 on my OSX/CI system.
> 
> Yichao Yu wrote:
>     I C. I guess Rene might have more to say about this but I also have a few comments.
>     
>     1. The configure options are in the README.md file. The one that control qt5 build is `ENABLE_QT5` not `QT5_BUILD` and it should be on by default.
>     2. There shouldn't be a problem building qt5 with x11 enabled on OSX, if not, please feel free to report it.
>     3. Qtcurve looks for xcb and x11-xcb, and the option that control whether it looks for them is QTC_ENABLE_X11. It does that using pkg-config not FindX11 so `CMAKE_DISABLE_FIND_PACKAGE_X11` won't do anything.
>     
>     I don't really understand why it doesn't build for Qt5. What's the configure output?
> 
> Yichao Yu wrote:
>     Also, since Rene mentioned that the Qt4 and Qt5 versions apparently cannot be built simultaneously on OSX, you should probably turn off the Qt4 build which is also on by default with the option `ENABLE_QT4`
> 
> Marko Käning wrote:
>     With these options
>     ```
>     configureExtraArgs=-DENABLE_QT4=false -DQTC_ENABLE_X11=false -DCMAKE_DISABLE_FIND_PACKAGE_X11=true
>     ```
>     I get this:
>     ```
>     -- Found PkgConfig: /opt/local/bin/pkg-config (found version "0.28")
>     -- checking for module 'xcb'
>     --   found xcb, version 1.11
>     -- checking for module 'gtk+-2.0'
>     --   package 'gtk+-2.0' not found
>     CMake Error at /opt/kde/install/darwin/mavericks/clang/shared/general/cmake/share/cmake-3.0/Modules/FindPkgConfig.cmake:341 (message):
>       A required package was not found
>     Call Stack (most recent call first):
>       /opt/kde/install/darwin/mavericks/clang/shared/general/cmake/share/cmake-3.0/Modules/FindPkgConfig.cmake:395 (_pkg_check_modules_internal)
>       CMakeLists.txt:118 (pkg_check_modules)
>     
>     
>     Package gtk+-2.0 was not found in the pkg-config search path.
>     Perhaps you should add the directory containing `gtk+-2.0.pc'
>     to the PKG_CONFIG_PATH environment variable
>     No package 'gtk+-2.0' found
>     -- checking for modules 'cairo;pangocairo'
>     --   package 'cairo' not found
>     --   package 'pangocairo' not found
>     CMake Error at /opt/kde/install/darwin/mavericks/clang/shared/general/cmake/share/cmake-3.0/Modules/FindPkgConfig.cmake:341 (message):
>       A required package was not found
>     Call Stack (most recent call first):
>       /opt/kde/install/darwin/mavericks/clang/shared/general/cmake/share/cmake-3.0/Modules/FindPkgConfig.cmake:395 (_pkg_check_modules_internal)
>       lib/cairo/CMakeLists.txt:11 (pkg_check_modules)
>     
>     
>     CMake Error at gtk2/style/CMakeLists.txt:58 (message):
>       Cannot find gdk-pixbuf-csource.
>     
>     
>     -- Configuring incomplete, errors occurred!
>     ```
>     
>     Can I build this also w/o GTK+?
> 
> René J.V. Bertin wrote:
>     Hi Marko,
>     
>     I built for Qt5 using the following cmake arguments:
>     
>     > -DQTC_QT4_STYLE_SUPPORT:BOOL=OFF -DENABLE_QT4:BOOL=OFF -DENABLE_QT5:BOOL=ON -DQTC_QT4_ENABLE_KWIN:BOOL=OFF -DCMAKE_C_COMPILER=/opt/local/bin/gcc-mp-4.8 -DCMAKE_CXX_COMPILER=/opt/local/bin/g++-mp-4.8 -DQTC_ENABLE_X11:BOOL=OFF -DQT_QMAKE_EXECUTABLE:FILEPATH=/usr/local/bin/qmake-5.3 -DCMAKE_PREFIX_PATH=/usr/local/qt/5/5.3/clang_64/lib/cmake/ -DCMAKE_MODULE_PATH=/usr/local/qt/5/5.3/clang_64/lib/cmake
>     
>     You probably won't need to specify the compiler on 10.9 .
> 
> Marko Käning wrote:
>     Looks like there is no way around GTK+?!
> 
> Marko Käning wrote:
>     This is what I get now after "sudo port install gtk2 -x11 +quartz":
>     ```
>     -- Build files have been written to: /Users/marko/WC/KDECI-builds/qtcurve/build
>     Scanning dependencies of target qtc_gtk2_check_on_hdr
>     Scanning dependencies of target qtc_gtk2_check_x_on_hdr
>     Scanning dependencies of target qt-dump-png
>     Scanning dependencies of target qtc_gtk2_blank16x16_hdr
>     [  1%] [  4%] [  4%] [  5%] Generating check_on-png.h
>     Generating check_x_on-png.h
>     Generating blank16x16-png.h
>     Building C object tools/CMakeFiles/qt-dump-png.dir/qt_dump_png.c.o
>     failed to load "/Users/marko/WC/KDECI-builds/qtcurve/data/blank16x16.png": Couldn't recognize the image file format for file '/Users/marko/WC/KDECI-builds/qtcurve/data/blank16x16.png'
>     failed to load "/Users/marko/WC/KDECI-builds/qtcurve/data/check_on.png": Couldn't recognize the image file format for file '/Users/marko/WC/KDECI-builds/qtcurve/data/check_on.png'
>     Linking C executable qt-dump-png
>     failed to load "/Users/marko/WC/KDECI-builds/qtcurve/data/check_x_on.png": Couldn't recognize the image file format for file '/Users/marko/WC/KDECI-builds/qtcurve/data/check_x_on.png'
>     make[2]: *** [gtk2/style/blank16x16-png.h] Error 1
>     make[2]: *** [gtk2/style/check_on-png.h] Error 1make[1]: *** [gtk2/style/CMakeFiles/qtc_gtk2_blank16x16_hdr.dir/all] Error 2
>     make[1]: *** Waiting for unfinished jobs....
>     make[2]: *** [gtk2/style/check_x_on-png.h] Error 1
>     make[1]: *** [gtk2/style/CMakeFiles/qtc_gtk2_check_x_on_hdr.dir/all] Error 2
>     make[1]: *** [gtk2/style/CMakeFiles/qtc_gtk2_check_on_hdr.dir/all] Error 2
>     ```
> 
> René J.V. Bertin wrote:
>     On my system GTk+ wasn't detected (and thus disabled) but you can add `-DENABLE_GTK2:BOOL=OFF` if required.
> 
> Marko Käning wrote:
>     OK, have disabled GTK2. Now I get further, but end up in tons of errors like these:
>     ```
>     In file included from /Users/marko/WC/KDECI-builds/qtcurve/qt5/common/common.h:927:
>     /Users/marko/WC/KDECI-builds/qtcurve/build/.cmake_utils_base/cmake_c_macros/include_fix/qtcurve-utils/color.h:31:9: warning: 'isnan' macro redefined
>     #define isnan(x)  std::isnan(x)
>             ^
>     /usr/include/math.h:178:9: note: previous definition is here
>     #define isnan(x)                                                         \
>             ^
>     .
>     .
>     .
>     In file included from /Users/marko/WC/KDECI-builds/qtcurve/qt5/common/common.h:927:
>     /Users/marko/WC/KDECI-builds/qtcurve/build/.cmake_utils_base/cmake_c_macros/include_fix/qtcurve-utils/color.h:259:16: error: no member named 'isnan' in namespace 'std'
>         } else if (isnan(amount)) {
>                    ^~~~~~~~~~~~~
>     ```
>     How to recover from that now?
> 
> Marko Käning wrote:
>     It looks as if color.h needs to get some #ifdef's around the isnan(x)-definition in order to avoid redefinition on OSX.
>     
>     Looks like /usr/include/math.h does not define isnan(x) on your 10.6.8 system, in contrast to my 10.9.5...
> 
> René J.V. Bertin wrote:
>     ow, seems I've pushed a bit too fast. You'll have seen that I handle Qt5 and Qt4 builds differently in that headerfile. 
>     
>     `man isnan` says that the function is defined in math.h ... maybe the code in color.h should simply invoke `::isnan` instead of a function that may or may not be a member of `std::`?
> 
> Marko Käning wrote:
>     This builds w/o problems if I remove the definition of isnan() alltogether.
> 
> Yichao Yu wrote:
>     That `std::isnan` is introduced by this very patchset and I have no idea what exactly works accross different OSX versions.
>     
>     @Rene
>     I think you can remove that `#include <math.h>`, it's already included (precisely for this function) in `utils.h`, if you really need `std::isnan` I guess you should include `<cmath>`, this won't work for the gtk version though (which maybe you don't care...)
>     
>     Also noted that this file will be used by both c and c++ code so please don't introduce any c++ only code unless it is only visible to c++ (e.g. only when Qt macros or `__cplusplus` is defined etc...)
> 
> René J.V. Bertin wrote:
>     I'll have to check again, tomorrow. Pity I forgot that, it was kind of on my list to have another look.
> 
> René J.V. Bertin wrote:
>     Marko: IIRC you also have a MacPorts tree with Qt4 installed (and presumably GTk2); could you please try to see how this style works out there for you?
>     If you do, please check if /Applications/MacPorts/Qt4/Assistant.app renders correctly for you. It doesn't for me (nor MacPort's Qt Creator; several widgets in the Project view overlap) and I'm *almost* sure it used to work. Yet I get the same issues when using the native style, even after uninstalling QtCurve, so I doesn't appear to be related.
> 
> Yichao Yu wrote:
>     I'm all fine with this as long as it doesn't break build on Linux. You can take all the time in the world to figure out how to make it work on OSX. =)
>     
>     That says, I'll be a little bit surprise if `isnan()` (the c function) is not provided by `<math.h>` on OSX since it is a standard C99 and posix function. If it is somehow really not provided in c++, include `<cmath>` and use `std::isnan` should probably fix it.
> 
> Marko Käning wrote:
>     isnan() is provided by <math.h> on OSX, which is why I could remove the define of isnan()
> 
> Marko Käning wrote:
>     Summing it up, this is what I need to change on the OSX/CI system in order to get qtcurve to build for Qt5:
>     ```
>     diff --git a/config/build/qtcurve/kf5-qt5.cfg b/config/build/qtcurve/kf5-qt5.cfg
>     new file mode 100644
>     index 0000000..da5c2b5
>     --- /dev/null
>     +++ b/config/build/qtcurve/kf5-qt5.cfg
>     @@ -0,0 +1,2 @@
>     +[DEFAULT]
>     +configureExtraArgs=-DQTC_ENABLE_X11=false -DCMAKE_DISABLE_FIND_PACKAGE_X11=true -DQTC_QT4_STYLE_SUPPORT:BOOL=OFF -DENABLE_QT4:BOOL=OFF -DENABLE_QT5:BOOL=ON -DQTC_QT4_ENABLE_KWIN:BOOL=OFF -DENABLE_GTK2:BOOL=OFF
>     diff --git a/patches/qtcurve/kf5-qt5/patch-lib_utils_color.h.diff b/patches/qtcurve/kf5-qt5/patch-lib_utils_color.h.diff
>     new file mode 100644
>     index 0000000..076d406
>     --- /dev/null
>     +++ b/patches/qtcurve/kf5-qt5/patch-lib_utils_color.h.diff
>     @@ -0,0 +1,14 @@
>     +diff --git lib/utils/color.h lib/utils/color.h
>     +index b8aae3c..bbd681c 100644
>     +--- lib/utils/color.h
>     ++++ lib/utils/color.h
>     +@@ -27,9 +27,6 @@
>     + #include "options.h"
>     + #ifdef Q_OS_MAC
>     + #include <math.h>
>     +-#if QT_VERSION >= 0x050000
>     +-#define isnan(x)  std::isnan(x)
>     +-#endif //QT_VERSION
>     + #endif // Q_OS_MAC
>     + 
>     + QTC_BEGIN_DECLS
>     ```
> 
> René J.V. Bertin wrote:
>     Marko, maybe you ought to open a specific review request for the new `kf5-qt5.cfg` file, so that it's better visible to people who can test it under Linux?
>     
>     As to the `isnan` issue: it's a real one. It beats me, but I get an undefined error when I build for Qt5 using MacPort's gcc 4.8, and this extract from `/opt/local/include/gcc48/c++/cmath` explains why:
>     
>     ```C++
>     // These are possible macros imported from C99-land.
>     #undef fpclassify
>     #undef isfinite
>     #undef isinf
>     #undef isnan
>     #undef isnormal
>     #undef signbit
>     #undef isgreater
>     #undef isgreaterequal
>     #undef isless
>     #undef islessequal
>     #undef islessgreater
>     #undef isunordered
>     ```
>     
>     No idea why this happens only when building for Qt5 and not for Qt4, a different compiler setting maybe?
>     
>     And I have no idea how to test for an inexistant symbol other than testing for the conditions in which it's known not to be defined. Including `cmath` before `math.h` doesn't solve this, presumably because the cpp file that includes `color.h` included the math header(s) first ...
>     I could see how feasible it is to check for the OS X version in color.h, but I do know how to avoid the error *you* were getting:
>     
>     ```C++
>     #if defined(Q_OS_MAC) || defined(__APPLE__)
>     #include <math.h>
>     #if QT_VERSION >= 0x050000 && !defined(isnan)
>     #define isnan(x)  std::isnan(x)
>     #endif //QT_VERSION
>     #endif // Q_OS_MAC
>     ```
>     
>     New here is the check for `!defined(isnan)` (and the `defined(__APPLE__)` which probably should have been there for completeness sake anyway. So this will define `isnan` only on OS X and building for Qt5 and when the function isn't already defined as a macro. 
>     Could you try this version please?
> 
> Yichao Yu wrote:
>     I found the same statements on my system but I have no idea why it is not triggered....
>     
>     Anyway, I don't want to deal with this stupid issue or figure out what is the right way to do it according to the standard. I changed it to use `isnan` for c and `std::isnan` for c++ and it at least compile on my system.
>     
>     Please try the current master....

Couldn't agree more - and works fine for me.


- René J.V.


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/120437/#review67714
-----------------------------------------------------------


On Sept. 30, 2014, 10:01 p.m., René J.V. Bertin wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/120437/
> -----------------------------------------------------------
> 
> (Updated Sept. 30, 2014, 10:01 p.m.)
> 
> 
> Review request for KDE Software on Mac OS X, André Marcelo Alvarenga, Yuri Chornoivan, and Yichao Yu.
> 
> 
> Repository: qtcurve
> 
> 
> Description
> -------
> 
> KDE is built on a cross-platform framework, and as such most applications (not directly linked to the Plasma desktop or X11) function or can be made to function fine.
> Qt will use a native style by default, but supports the same style plugins as it does on other platforms, which bring the advantage of better (more precise) and more compact layout, without by definition reducing integration with the OS X desktop.
> 
> As such, QtCurve 1.8.14 worked "out of the box" (http://kde-look.org/content/show.php?content=40492, source from http://craigd.wikispaces.com/file/view) and I created a MacPorts port for it (https://trac.macports.org/ticket/44527). With the `kde4-workspace` port installed, one has almost the full customisation experience, minus everything window-manager related of course, nor full control of window backgrounds (not allowed by Qt and/or OS X).
> 
> The current version, which has seen many changes that require X11, was less straightforward to get to work, requiring a considerable collection of small changes.
> 
> The brunt of the present patchset consists of making the code in question conditional on the presence of `Q_WS_X11`, `Q_OS_MAC`, `__MACH__` or `__APPLE__` in non Qt code and `APPLE` in the cmake files. A few patches introduce functions not available on OS X (getline) or replace them with OS X specifics (`clock_gettime` -> `mach_absolute_timer`, nicely initialised with a dylib constructor function :) ) while others simply ensure that header files are found (or inexistent ones ignored).
> The only functional guess/change I made is in `setOpacityProp()`, where I added a `w->setWindowOpacity( 0.01 * opacity )` for non Q_WS_X11 code, presuming that `prop` is simply on the 0-100 percentage as exposed in the preferences dialog.
> 
> 
> Diffs
> -----
> 
>   CMakeLists.txt f76fd1b 
>   gtk2/common/config_file.c d732ca9 
>   gtk2/style/CMakeLists.txt 01e8891 
>   gtk2/style/qt_settings.c f5a5c98 
>   lib/cairo/CMakeLists.txt c66c63c 
>   lib/utils/CMakeLists.txt 15757ed 
>   lib/utils/color.h 2c7081f 
>   lib/utils/map.c a829e9e 
>   lib/utils/process.c f2490ef 
>   lib/utils/timer.c 879451e 
>   qt4/config/CMakeLists.txt 15454e6 
>   qt4/config/exportthemedialog.h 42590ec 
>   qt4/config/exportthemedialog.cpp f39b86d 
>   qt4/kwin/CMakeLists.txt 654604b 
>   qt4/kwinconfig/CMakeLists.txt cbd8b62 
>   qt4/style/CMakeLists.txt f38d029 
>   qt4/style/qtcurve.cpp 7346c2f 
>   qt4/style/qtcurve_plugin.cpp f390da4 
>   qt5/CMakeLists.txt 1d0359e 
>   qt5/style/CMakeLists.txt b6cb222 
> 
> Diff: https://git.reviewboard.kde.org/r/120437/diff/
> 
> 
> Testing
> -------
> 
> On OS X 10.6.8 against kdelibs 4.14.1 and Qt 4.8.6 . This OS requires to build v1.8.18 with a gcc version from MacPorts in order to get the necessary C++11 support; newer OS versions will use a recent clang version (system compiler).
> 
> - Qt4/KDE4 support: OK (see screenshot)
> - GTk2 support: OK
> - X11 support: builds but I have no idea what it's supposed to do
> - Qt5 support: OK (against Qt 5.3.1 obtained with Digia's installer)
> 
> I tested building on Linux (Kubuntu 14.04, KDE SC 4.13.3, using clang 3.4) after the 2nd update to the patchset and that worked fine.
> One issue that could use attention is the Qt5 detection: Qt5.3 is apparently required and `ENABLE_QT5` is not unset when an earlier Qt5 version is found instead.
> 
> 
> File Attachments
> ----------------
> 
> sample showing a native file dialog for comparison
>   https://git.reviewboard.kde.org/media/uploaded/files/2014/09/30/02545bef-04d2-4a45-8955-e13bf7d063a0__Screen_shot_2014-09-30_at_14.05.54.png
> KDE4 systemsettings and the QtCurve configuration dialog
>   https://git.reviewboard.kde.org/media/uploaded/files/2014/09/30/fe5564f2-5e4e-485a-96d7-d192ff104261__QtCurve-1818.png
> KDE4 systemsettings and QtCurve config dialog with QtCuve 1.8.14, for comparison
>   https://git.reviewboard.kde.org/media/uploaded/files/2014/09/30/6bd8dd5a-9b94-43c3-88d9-c9be32a56b72__QtCurve-1814.png
> a little convenience file for uploading to RB from KDevelop
>   https://git.reviewboard.kde.org/media/uploaded/files/2014/09/30/39207a85-4092-4ea1-a181-051d0db5bb96__.reviewboardrc
> 
> 
> Thanks,
> 
> René J.V. Bertin
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-mac/attachments/20141001/cddf8ac1/attachment-0001.html>


More information about the kde-mac mailing list