> 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 > >
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
