Review Request 124892: bug 342962: kdeclarative plugins should be built as a bundle plugin and not a shared library

[David Faure]

> On Aug. 25, 2015, 1:41 p.m., David Edmundson wrote:
> > I've got both Gentoo and Arch saying this causes a major problem [1]:
> > 
> > libdraganddropplugin.so changes to draganddropplugin.so
> > in /usr/lib/qt/qml/org/kde/draganddrop
> > 
> > and then they don't get loaded.
> > 
> > any ideas? Otherwise I'll have to revert this before release.
> > 
> > [1] https://aur.archlinux.org/packages/plasma-desktop-git/
> 
> Harald Sitter wrote:
>     I tried it this morning and it seemed to work. Now I try it again and it fails....
>     
>     I suppose this is the point where we call for a revert hammer? :P
> 
> Harald Sitter wrote:
>     from qmldir documentation
>     
>     Declares a plugin to be made available by the module.
>     <Name> is the plugin library name. This is usually not the same as the file name of the plugin binary, which is platform dependent; e.g. the library MyAppTypes would produce libMyAppTypes.so on Linux and MyAppTypes.dll on Windows.
> 
> Harald Sitter wrote:
>     http://www.cmake.org/cmake/help/v3.0/variable/CMAKE_SHARED_MODULE_PREFIX.html
> 
> David Edmundson wrote:
>     are we meant to set that to "lib" in every project? That doesn't sound right.
> 
> Harald Sitter wrote:
>     More like per-target even, since a kded plugin for example wouldn't want the prefix I suppose. It might well be that switching the qml plugins to MODULE is quite simply not the best solution to the initial problem on OSX, even though TBH they are really MODULE and not SHARED anyway so by any measure declaring them SHARED was weird all along.
>     alexmerry might know of a better way but from my quick research it appears that either we need to set the prefix variable (supposedly via a macro wrapping add_library) or we revert back to SHARED and need to find another way to coerce cmake into producing working results on OSX.
>     
>     In a way I would argue that the problem is more with the qml loader not looking for a version without lib prefix if the lib prefix one is not available. So, regardless of how we proceed with kdeclarative I think it would be wortwhile to possible expand the qml loader to not require the lib prefix on unix systems. If not to resolve the issue at hand, at least to have it behave reasonably in the distant future.
> 
> René J.V. Bertin wrote:
>     > find another way to coerce cmake into producing working results on OSX
>     
>     Are you sure that results actually "do no not work" on OS X (and that this has nothing to do with QStandardPaths returning unexpected locations)?!
>     It is always possible to ensure that the plugins get the correct install_name and even a compatibility_version if there's any point in that (do these get versioning under Linux?). This can be done during the link step but also afterwards (probably more complicated to get right in CMake scripts). Whatever the approach, it should be possible to do it in the CMake macro (cmake already generates an option to set the install_name because otherwise the linker would either assume a relative install_name [just the filename] or use the full path to the output file).
>     
>     I presume that at least some of the plugins targeted here exists for KDE4 and if so, are still built the way they were there?

Harald: you are right, Qt requiring the lib prefix is incorrect (unnecessary and confusing) on Linux, since as you say, a module is not a shared lib.
QLibrary actually tries with and without the lib prefix (which is why C++ plugins like kded and others don't have it). I assume QML doesn't use QLibrary then?


- David


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


On Aug. 23, 2015, 9:16 p.m., Hanspeter Niederstrasser wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/124892/
> -----------------------------------------------------------
> 
> (Updated Aug. 23, 2015, 9:16 p.m.)
> 
> 
> Review request for Build System, KDE Software on Mac OS X, KDE Frameworks, Plasma, and Harald Sitter.
> 
> 
> Bugs: 342962
>     https://bugs.kde.org/show_bug.cgi?id=342962
> 
> 
> Repository: kdeclarative
> 
> 
> Description
> -------
> 
> The kdeclarative plugins (draganddropplugin, kcoreaddonsplugin, kio, kquickcontrolsprivateplugin, and kquickcontrolsaddonsplugin) are being built as shared libraries. They should be built as bundles (MODULE) in the CMakeLists.txt file.
> 
> When built as SHARED as in the current code, libdraganddropplugin.dylib gets installed to $PREFIX/share/qt5/qml/org/kde/draganddrop, but is given an OS X install_name of $PREFIX/lib/libdraganddropplugin.dylib. This mismatch can cause problems. It is also given a compatibility_version of 0.0.0.
> 
> 
> Diffs
> -----
> 
>   src/qmlcontrols/draganddrop/CMakeLists.txt e8127e4 
>   src/qmlcontrols/kcoreaddons/CMakeLists.txt 3f77f2d 
>   src/qmlcontrols/kioplugin/CMakeLists.txt 7b258e0 
>   src/qmlcontrols/kquickcontrols/private/CMakeLists.txt da355c1 
>   src/qmlcontrols/kquickcontrolsaddons/CMakeLists.txt 5b711e1 
> 
> Diff: https://git.reviewboard.kde.org/r/124892/diff/
> 
> 
> Testing
> -------
> 
> Since the plugin is not supposed to be a linkable library, it should be built as MODULE in CMakeLists.txt. The physical install location remains the same and plugins don't have install_names. This corrects the install_name/install location mismatch. The change should not have any effect on non-OS X systems.
> 
> 
> Thanks,
> 
> Hanspeter Niederstrasser
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-buildsystem/attachments/20150826/aea00ddd/attachment.html>