[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-panel-devel
Subject: Re: Review Request 124892: bug 342962: kdeclarative plugins should be built as a bundle plugin and n
From: René J.V. Bertin <rjvbertin () gmail ! com>
Date: 2015-08-25 16:27:31
Message-ID: 20150825162731.4103.83637 () mimi ! kde ! org
[Download RAW message or body]
--===============6330467684167053504==
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
> On Aug. 25, 2015, 3: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.
> 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?
- René J.V.
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/124892/#review84333
-----------------------------------------------------------
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
>
>
--===============6330467684167053504==
MIME-Version: 1.0
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: 8bit
<html>
<body>
<div style="font-family: Verdana, Arial, Helvetica, Sans-Serif;">
<table bgcolor="#f9f3c9" width="100%" cellpadding="12" style="border: 1px #c9c399 \
solid; border-radius: 6px; -moz-border-radius: 6px; -webkit-border-radius: 6px;"> \
<tr> <td>
This is an automatically generated e-mail. To reply, visit:
<a href="https://git.reviewboard.kde.org/r/124892/">https://git.reviewboard.kde.org/r/124892/</a>
</td>
</tr>
</table>
<br />
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: \
10px;"> <p style="margin-top: 0;">On August 25th, 2015, 3:41 p.m. CEST, <b>David \
Edmundson</b> wrote:</p> <blockquote style="margin-left: 1em; border-left: 2px solid \
#d0d0d0; padding-left: 10px;"> <pre style="white-space: pre-wrap; white-space: \
-moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: \
break-word;"><p style="padding: 0;text-rendering: inherit;margin: 0;line-height: \
inherit;white-space: inherit;">I've got both Gentoo and Arch saying this causes a \
major problem [1]:</p> <p style="padding: 0;text-rendering: inherit;margin: \
0;line-height: inherit;white-space: inherit;">libdraganddropplugin.so changes to \
draganddropplugin.so in /usr/lib/qt/qml/org/kde/draganddrop</p>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: \
inherit;white-space: inherit;">and then they don't get loaded.</p> <p style="padding: \
0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">any \
ideas? Otherwise I'll have to revert this before release.</p> <p style="padding: \
0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">[1] \
https://aur.archlinux.org/packages/plasma-desktop-git/</p></pre> </blockquote>
<p>On August 25th, 2015, 3:49 p.m. CEST, <b>Harald Sitter</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: \
10px;"> <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><p style="padding: \
0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">I \
tried it this morning and it seemed to work. Now I try it again and it fails....</p> \
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: \
inherit;white-space: inherit;">I suppose this is the point where we call for a revert \
hammer? :P</p></pre> </blockquote>
<p>On August 25th, 2015, 3:52 p.m. CEST, <b>Harald Sitter</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: \
10px;"> <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><p style="padding: \
0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">from \
qmldir documentation</p> <p style="padding: 0;text-rendering: inherit;margin: \
0;line-height: inherit;white-space: inherit;">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.</p></pre> </blockquote>
<p>On August 25th, 2015, 3:59 p.m. CEST, <b>Harald Sitter</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: \
10px;"> <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><p style="padding: \
0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: \
inherit;">http://www.cmake.org/cmake/help/v3.0/variable/CMAKE_SHARED_MODULE_PREFIX.html</p></pre>
</blockquote>
<p>On August 25th, 2015, 4:09 p.m. CEST, <b>David Edmundson</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: \
10px;"> <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><p style="padding: \
0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">are \
we meant to set that to "lib" in every project? That doesn't sound right.</p></pre> \
</blockquote>
<p>On August 25th, 2015, 4:36 p.m. CEST, <b>Harald Sitter</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: \
10px;"> <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><p style="padding: \
0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">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.</p> <p style="padding: 0;text-rendering: \
inherit;margin: 0;line-height: inherit;white-space: inherit;">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.</p></pre> </blockquote>
</blockquote>
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><blockquote \
style="text-rendering: inherit;padding: 0 0 0 1em;border-left: 1px solid \
#bbb;white-space: normal;margin: 0 0 0 0.5em;line-height: inherit;"> <p \
style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: \
inherit;">find another way to coerce cmake into producing working results on OSX</p> \
</blockquote> <p style="padding: 0;text-rendering: inherit;margin: 0;line-height: \
inherit;white-space: inherit;">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).</p> <p style="padding: 0;text-rendering: inherit;margin: 0;line-height: \
inherit;white-space: inherit;">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?</p></pre> \
<br />
<p>- René J.V.</p>
<br />
<p>On August 23rd, 2015, 11:16 p.m. CEST, Hanspeter Niederstrasser wrote:</p>
<table bgcolor="#fefadf" width="100%" cellspacing="0" cellpadding="12" style="border: \
1px #888a85 solid; border-radius: 6px; -moz-border-radius: 6px; \
-webkit-border-radius: 6px;"> <tr>
<td>
<div>Review request for Build System, KDE Software on Mac OS X, KDE Frameworks, \
Plasma, and Harald Sitter.</div> <div>By Hanspeter Niederstrasser.</div>
<p style="color: grey;"><i>Updated Aug. 23, 2015, 11:16 p.m.</i></p>
<div style="margin-top: 1.5em;">
<b style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Bugs: </b>
<a href="https://bugs.kde.org/show_bug.cgi?id=342962">342962</a>
</div>
<div style="margin-top: 1.5em;">
<b style="color: #575012; font-size: 10pt;">Repository: </b>
kdeclarative
</div>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Description </h1>
<table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" \
style="border: 1px solid #b8b5a0"> <tr>
<td>
<pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: \
-moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: \
break-word;"><p style="padding: 0;text-rendering: inherit;margin: 0;line-height: \
inherit;white-space: inherit;">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.</p> <p style="padding: 0;text-rendering: inherit;margin: \
0;line-height: inherit;white-space: inherit;">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.</p></pre> </td>
</tr>
</table>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Testing </h1>
<table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" style="border: \
1px solid #b8b5a0"> <tr>
<td>
<pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: \
-moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: \
break-word;"><p style="padding: 0;text-rendering: inherit;margin: 0;line-height: \
inherit;white-space: inherit;">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.</p></pre> </td>
</tr>
</table>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Diffs</b> </h1>
<ul style="margin-left: 3em; padding-left: 0;">
<li>src/qmlcontrols/draganddrop/CMakeLists.txt <span style="color: \
grey">(e8127e4)</span></li>
<li>src/qmlcontrols/kcoreaddons/CMakeLists.txt <span style="color: \
grey">(3f77f2d)</span></li>
<li>src/qmlcontrols/kioplugin/CMakeLists.txt <span style="color: \
grey">(7b258e0)</span></li>
<li>src/qmlcontrols/kquickcontrols/private/CMakeLists.txt <span style="color: \
grey">(da355c1)</span></li>
<li>src/qmlcontrols/kquickcontrolsaddons/CMakeLists.txt <span style="color: \
grey">(5b711e1)</span></li>
</ul>
<p><a href="https://git.reviewboard.kde.org/r/124892/diff/" style="margin-left: \
3em;">View Diff</a></p>
</td>
</tr>
</table>
</div>
</body>
</html>
--===============6330467684167053504==--
[Attachment #3 (text/plain)]
_______________________________________________
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic