Re: Review Request 124892: bug 342962: kdeclarative plugins should be built as a bundle plugin and not a shared library
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124892/ --- (Updated Aug. 31, 2015, 9:10 p.m.) Status -- This change has been discarded. 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 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 124892: bug 342962: kdeclarative plugins should be built as a bundle plugin and not a shared library
On Aug. 25, 2015, 2:22 p.m., René J.V. Bertin wrote: 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. Both properties are used only when the `dylib` is used as a shared library, because AFAIK they're only used by the dynamic loader when the reference information is available (i.e. stored in the binary by the link editor). Using `dlopen` on a random file, dylib or other, does not provide such information and thus it shouldn't matter what the loaded file claims for its install_name and/or compatibility_version. By contrast, there *is* a difference between shared libraries and loadable modules (plugins or `bundles` in OS X speak) on OS X. The latter cannot be used as shared libraries by the link editor (something that certain KDE4 projects sin against) while the former can be used as plugins without any issue. However, only plugins can have automatic access to the loader's symbols but that requires the loader to be specified at link time so not of much interest for generic plugins, kparts etc. NB: the `bundle` in this context is unfortunate because they are not generally bundles in the app bundle way. NB2: those KDE projects that use modules as shared libraries (kparts, in unit tests IIRC) led me to propose a patch to MacPorts's port:cmake which made cmake create modules with the same linker options as shared libraries (i.e. `-dynamiclib` instead of `-bundle`). I've since tried to get that patch removed, but it is still out there. Marco Martin wrote: if this breaks on linux, it should be reverted for now Reverted for now. I also reopened the bug report. Also for the qml side of things: https://mail.kde.org/pipermail/kde-frameworks-devel/2015-August/026281.html - Harald --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124892/#review84338 --- 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 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 124892: bug 342962: kdeclarative plugins should be built as a bundle plugin and not a shared library
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
Re: Review Request 124892: bug 342962: kdeclarative plugins should be built as a bundle plugin and not a shared library
On Aug. 25, 2015, 2:22 p.m., René J.V. Bertin wrote: 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. Both properties are used only when the `dylib` is used as a shared library, because AFAIK they're only used by the dynamic loader when the reference information is available (i.e. stored in the binary by the link editor). Using `dlopen` on a random file, dylib or other, does not provide such information and thus it shouldn't matter what the loaded file claims for its install_name and/or compatibility_version. By contrast, there *is* a difference between shared libraries and loadable modules (plugins or `bundles` in OS X speak) on OS X. The latter cannot be used as shared libraries by the link editor (something that certain KDE4 projects sin against) while the former can be used as plugins without any issue. However, only plugins can have automatic access to the loader's symbols but that requires the loader to be specified at link time so not of much interest for generic plugins, kparts etc. NB: the `bundle` in this context is unfortunate because they are not generally bundles in the app bundle way. NB2: those KDE projects that use modules as shared libraries (kparts, in unit tests IIRC) led me to propose a patch to MacPorts's port:cmake which made cmake create modules with the same linker options as shared libraries (i.e. `-dynamiclib` instead of `-bundle`). I've since tried to get that patch removed, but it is still out there. if this breaks on linux, it should be reverted for now - Marco --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124892/#review84338 --- 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 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 124892: bug 342962: kdeclarative plugins should be built as a bundle plugin and not a shared library
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. http://www.cmake.org/cmake/help/v3.0/variable/CMAKE_SHARED_MODULE_PREFIX.html - 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 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 124892: bug 342962: kdeclarative plugins should be built as a bundle plugin and not a shared library
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 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 124892: bug 342962: kdeclarative plugins should be built as a bundle plugin and not a shared library
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124892/#review84338 --- 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. Both properties are used only when the `dylib` is used as a shared library, because AFAIK they're only used by the dynamic loader when the reference information is available (i.e. stored in the binary by the link editor). Using `dlopen` on a random file, dylib or other, does not provide such information and thus it shouldn't matter what the loaded file claims for its install_name and/or compatibility_version. By contrast, there *is* a difference between shared libraries and loadable modules (plugins or `bundles` in OS X speak) on OS X. The latter cannot be used as shared libraries by the link editor (something that certain KDE4 projects sin against) while the former can be used as plugins without any issue. However, only plugins can have automatic access to the loader's symbols but that requires the loader to be specified at link time so not of much interest for generic plugins, kparts etc. NB: the `bundle` in this context is unfortunate because they are not generally bundles in the app bundle way. NB2: those KDE projects that use modules as shared libraries (kparts, in unit tests IIRC) led me to propose a patch to MacPorts's port:cmake which made cmake create modules with the same linker options as shared libraries (i.e. `-dynamiclib` instead of `-bundle`). I've since tried to get that patch removed, but it is still out there. - René J.V. Bertin On Aug. 23, 2015, 11: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, 11: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 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 124892: bug 342962: kdeclarative plugins should be built as a bundle plugin and not a shared library
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 are we meant to set that to lib in every project? That doesn't sound right. - 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 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 124892: bug 342962: kdeclarative plugins should be built as a bundle plugin and not a shared library
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 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 --- 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 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 124892: bug 342962: kdeclarative plugins should be built as a bundle plugin and not a shared library
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124892/#review84333 --- 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/ - David Edmundson 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 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 124892: bug 342962: kdeclarative plugins should be built as a bundle plugin and not a shared library
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/ 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 --- 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 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 124892: bug 342962: kdeclarative plugins should be built as a bundle plugin and not a shared library
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124892/#review84226 --- Ship it! I'm not Harald, but no. it won't. - Sune Vuorela On Aug. 23, 2015, 3:22 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, 3:22 p.m.) Review request for Build System, KDE Software on Mac OS X, KDE Frameworks, Plasma, and Harald Sitter. 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 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 124892: bug 342962: kdeclarative plugins should be built as a bundle plugin and not a shared library
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124892/ --- (Updated Aug. 23, 2015, 1:26 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 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 124892: bug 342962: kdeclarative plugins should be built as a bundle plugin and not a shared library
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124892/#review84233 --- Ship it! Ship It! - Hanspeter Niederstrasser On Aug. 23, 2015, 1:26 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, 1:26 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 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 124892: bug 342962: kdeclarative plugins should be built as a bundle plugin and not a shared library
On Aug. 23, 2015, 1:36 p.m., Hanspeter Niederstrasser wrote: Ship It! Oops. My pressing Ship it doesn't actually commit. Someone with write access will have to push upstream. Thanks. - Hanspeter --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124892/#review84233 --- On Aug. 23, 2015, 1:26 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, 1:26 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 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 124892: bug 342962: kdeclarative plugins should be built as a bundle plugin and not a shared library
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124892/#review84220 --- +1 seems to make sense but it's not really my area, wait a day or two in case anyone else comments before shipping it - David Edmundson On Aug. 23, 2015, 1:02 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, 1:02 p.m.) Review request for Build System, KDE Software on Mac OS X, KDE Frameworks, and Plasma. 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 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 124892: bug 342962: kdeclarative plugins should be built as a bundle plugin and not a shared library
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124892/#review84222 --- +1 from me also, but could you add Harald Sitter to the reviewers (or someone else familiar with Linux library packaging) to confirm that it won't cause compatilibity issues? - Alex Merry On Aug. 23, 2015, 1:02 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, 1:02 p.m.) Review request for Build System, KDE Software on Mac OS X, KDE Frameworks, and Plasma. 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 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 124892: bug 342962: kdeclarative plugins should be built as a bundle plugin and not a shared library
--- 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.) Status -- This change has been marked as submitted. Review request for Build System, KDE Software on Mac OS X, KDE Frameworks, Plasma, and Harald Sitter. Changes --- Submitted with commit 383aa77ebf0b08adca13ce67a90f61c9c6a65851 by David Edmundson on behalf of Hanspeter Niederstrasser to branch master. 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 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
