Improve compatibility with OS X #5
Conversation
| @@ -222,6 +227,9 @@ endmacro() | |||
| macro (rock_find_qt4) | |||
| find_package(Qt4 REQUIRED QtCore QtGui QtOpenGl ${ARGN}) | |||
| include_directories(${QT_HEADERS_DIR}) | |||
| include_directories(${QT_QTCORE_INCLUDE_DIR}) | |||
There was a problem hiding this comment.
@D-Alex: These should already be included in the foreach() just below.
|
@D-Alex: Ping. Could you have a look at this Qt thing ? |
Conflicts: modules/Rock.cmake
|
sounds fair - I updated the pull request |
|
Sorry I am taking so long with this one. It breaks compilation on non-OSX targets because one cannot link a module to another module. This is a major problem with the qt stuff, as we need to compile with MODULE to allow loading through the qt plugin system, and with SHARED to use a widget directly. We'll probably have to compile the plugin separately from the shared library. |
|
One general question which came me just in mind. The "Normal" way (then we can influence the build-type from autobuild/autoproj) could be by seeting (if needed packagewise):
|
I would not mind changing this. Now, switching to static libs usually does not work because of PIC issues, linking order, ... In other words, if the goal is to support building Rock with static libs, we would have to IMO be serious about it. |
|
You are right. But linking against libraries in the install/qt/desginer folder is very ugly anyway. Do you think changing it would introduce to much trouble? Every one has probably to recompile its installation. |
Loadable modules don't need a pkg-config file (actually, the file is basically useless). In the end, only rock_library needs to generate the file.. This commit moves the call to rock_prepare_pkgconfig to rock_library. It also makes the call strict (you have to mean it if you call it), and promotes the warning about a missing pkg-config file (now in rock_library) to WARNING
|
Wait ... The one thing is this SHARED stuff ... That I would leave it to people that have more experience than me about linking with static libs (my experience being "it really does not work out of the box") The other one is this module vs. shared lib thing. I am preparing a patch to split the vizkit plugins (widget & vizkit3d) into a shared lib part in lib/ and a module part installed wherever it is expected. The problem, however, is that it requires to rename the plugin lib (I currently append -plugin) because they're both built within the same folder (having two targets with the same output name in the same folder is something cmake does not support). Which means that we'll either have to do quite a bit more work, or have to update vizkit to search files with this plugin. While we're at it, we should probably move the vizkit3d plugins into their own subfolder of lib/ Thoughts ? |
"Recent" cmake (post-2.2) will refuse to link to a module. Since MacOSX requires to make the distinction between modules and shared libs, we have to split the Qt plugins between the module part and the shared lib part. This introduces a backward compatible mode, where we basically build the shared lib twice. However, if the rock_vizkit_widget stanza is updated to use the new QTPLUGIN <sourcefile> flag, it then links the module to the shared lib, only adding the qtplugin file to the module. To make this work, I had to start installing the vizkit3d plugins from lib/ to lib/vizkit3d - to avoid name clashes between the pure shared library and the plugin
|
Related pull request: |
fix vizkit(3d) plugin compilation on non-OSX platforms
|
works fine on mac os - thx |
|
Actually, this is broken. On cmake 2.8 (Ubuntu 14.10) CMake randomly picks either of the two libraries (lib or module) and installs it in both places. We'll either have to find a workaround, or install the plugin with a suffix. I would prefer a workaround, but I don't really know what to try ... |
|
Is this PR still needed after: or can it be closed? |
|
Yes. This is unrelated. The main issue here is that vizkit3d plugins (qt plugins) cannot be used as pure shared libraries on MacOSX, which is troublesome. We would have to create both a module and a library, but cmake has a bug that makes it fail. So, now, someone would have to test a patched vizkit where the Qt plugins would have a suffix (e.g. -module). Or find a better way. |
No description provided.