[KDE/Mac] Review Request 122115: [OS X] source code adaptations to OS X

René J.V. Bertin rjvbertin at gmail.com
Tue Jan 20 20:07:19 UTC 2015



> On Jan. 19, 2015, 12:10 p.m., Friedrich W. H. Kossebau wrote:
> > krita/ui/opengl/kis_opengl_canvas2_p.h, line 38
> > <https://git.reviewboard.kde.org/r/122115/diff/1/?file=342473#file342473line38>
> >
> >     "// RJVB" is not a perfect comment ;) Please add here a comment why this is done.
> >     
> >     In the RR you say:
> >     "typedef void* GLsync: in order not to impose a required dependency on GLEW."
> >     How exactly does that work? Because for me it breaks compilation on a system wher GLEW is not installed. Can we please fix this?
> 
> René J.V. Bertin wrote:
>     What are your symptoms on a system without GLEW?
>     
>     Problems is I cannot currently allocate the resources to do a full Krita build (I lost my build tree), so experimenting will have to wait.
>     
>     The way this worked for me before I installed MacPorts glew is that it provides a type normally defined in gltypes.h and that is expected to be available even if you don't have glew.
>     Or at least that was the case a couple months back when I introduced this change, but it still seems to be true (cf. line 316 in the same header file).
>     
>     What I can propose (and what you can commit if you're in a hurry) is to do this:
>     
>     ```
>     #if defined(Q_OS_MAC) && !defined(HAVE_GLEW)
>         // provide the GLsync type even if GLEW is not available
>     	typedef void* GLsync;
>     #endif
>     ```
> 
> Friedrich W. H. Kossebau wrote:
>     Symptom is this:
>     ```
>     [ 50%] Building CXX object krita/ui/CMakeFiles/kritaui.dir/opengl/kis_opengl_canvas2.cpp.o
>     In file included from /home/kossebau/Daten/Projekte/Calligra/calligra.master/krita/ui/opengl/kis_opengl_canvas2.cpp:59:0:
>     /home/kossebau/Daten/Projekte/Calligra/calligra.master/krita/ui/opengl/kis_opengl_canvas2_p.h:38:16: error: conflicting declaration ‘typedef void* GLsync’
>       typedef void* GLsync;
>                     ^
>     In file included from /usr/include/GL/gl.h:2055:0,
>                      from /usr/include/GL/glu.h:38,
>                      from /home/kossebau/Daten/Projekte/Calligra/calligra.master/krita/ui/opengl/kis_opengl.h:41,
>                      from /home/kossebau/Daten/Projekte/Calligra/calligra.master/krita/ui/opengl/kis_opengl_canvas2.h:22,
>                      from /home/kossebau/Daten/Projekte/Calligra/calligra.master/krita/ui/opengl/kis_opengl_canvas2.cpp:21:
>     /usr/include/GL/glext.h:1369:26: error: ‘GLsync’ has a previous declaration as ‘typedef struct __GLsync* GLsync’
>      typedef struct __GLsync *GLsync;
>                               ^
>     krita/ui/CMakeFiles/kritaui.dir/build.make:3072: recipe for target 'krita/ui/CMakeFiles/kritaui.dir/opengl/kis_opengl_canvas2.cpp.o' failed
>     ```
>     where `/usr/include/GL/glext.h` is from `Mesa-libGL-devel | GL/GLX development files of the OpenGL API` here on my OpenSUSE.
>     
>     No clue about OpenGL and all the different packages, so cannot yet derive any proposal/idea from that.

Ah, for once the X11-based build has been bitten by an assumption based on an OS X build :)

I wasn't aware that GLsync is also defined in a non-GLEW headerfile like glext.h ... and I cannot even affirm at the moment that that file isn't going to be included on OS X. Will have to check that when I redo my build without support for GLEW. And then see if I still run into issues with the GLsync type.

Meanwhile, do feel free to reverse this particular change, or to apply the additional check suggested above.

Really annoying C/C++ never provided a means to test for the existence of a type!


- René J.V.


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


On Jan. 18, 2015, 5:09 p.m., René J.V. Bertin wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/122115/
> -----------------------------------------------------------
> 
> (Updated Jan. 18, 2015, 5:09 p.m.)
> 
> 
> Review request for Calligra and KDE Software on Mac OS X.
> 
> 
> Repository: calligra
> 
> 
> Description
> -------
> 
> This patch is a companion to the build system adaptations from RR 122114(https://git.reviewboard.kde.org/r/122114/), and includes a number of adaptations to OS X peculiarities.
> 
> In order of appearance in the patch file:
> - OS X has a so-called `application menu` which has a number of standard `menu items` (actions in Qt speak): About, Preferences and Quit. Qt tries to guess which actions are to be assigned to these menu items, in a 1st come, 1st served fashion and using text-based heuristics on the action text. This works reliably enough for Quit, but not so for the About and Preferences items which both tend to have multiple matches in KDE menus. For this reason it is good practice to `setMenuRole` on the relevant actions when they are created.
> - `typedef void* GLsync`: in order not to impose a required dependency on GLEW.
> - KDE applications commonly use the `.so` extension for shared modules and plugins, and the build system creates them that way.
> 
> 
> Diffs
> -----
> 
>   flow/part/FlowView.cpp 5ce755f 
>   karbon/ui/KarbonView.cpp db71464 
>   krita/ui/opengl/kis_opengl_canvas2_p.h 16ba118 
>   libs/db/drivers/sqlite/sqliteconnection.cpp 23a6eca 
>   libs/kopageapp/KoPAView.cpp fa0e381 
>   words/part/KWView.cpp 9f2f230 
> 
> Diff: https://git.reviewboard.kde.org/r/122115/diff/
> 
> 
> Testing
> -------
> 
> On OS X 10.9.5 with kdelibs 4.14.4 and Qt 4.8.6, on a mid 2011 13" Macbook Pro (2.7Ghz dual-core i7, Intel HD3000 graphics)
> 
> 
> Thanks,
> 
> René J.V. Bertin
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-mac/attachments/20150120/26f04269/attachment.html>


More information about the kde-mac mailing list