> 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.
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. - Harald ----------------------------------------------------------- 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
