<html>
<body>
<div style="font-family: Verdana, Arial, Helvetica, Sans-Serif;">
<table bgcolor="#f9f3c9" width="100%" cellpadding="8" style="border: 1px #c9c399 solid;">
<tr>
<td>
This is an automatically generated e-mail. To reply, visit:
<a href="http://git.reviewboard.kde.org/r/105126/">http://git.reviewboard.kde.org/r/105126/</a>
</td>
</tr>
</table>
<br />
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<p style="margin-top: 0;">On June 1st, 2012, 6:58 p.m., <b>Allen Winter</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;">since kdepimlibs installs a few FindFoo.cmake modules on its own, adjusting the CMAKE_MODULE_PATH to point to that installation location makes sense to me. and prepending also makes sense.
Let's wait for krop to comment on this.
also you might consider adding the buildsystem group to this review so the CMake experts can take a look</pre>
</blockquote>
<p>On June 1st, 2012, 8:32 p.m., <b>Christophe Giboudeaux</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;">Marc would know more. I think the installed FindGpgme.cmake is the reason for the CMAKE_MODULE_PATH order. FindQGpgme calls FindGpgme and expects certains variables to be set.
</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;">It seems a bit, well, anti-social to prepend the path. The system path (for the modules provided by cmake itself) should never be put in CMAKE_MODULE_PATH, so I don't think it should matter for FindQGpgme whether the path is prepended or appended, but when a project initially sets CMAKE_MODULE_PATH to something in its local source directory, I think it's reasonable for that project to assume that those local modules will override any other modules from anywhere else. KdepimLibsConfig.cmake violates that.</pre>
<br />
<p>- Alex</p>
<br />
<p>On June 2nd, 2012, 11:20 p.m., Alex Merry wrote:</p>
<table bgcolor="#fefadf" width="100%" cellspacing="0" cellpadding="8" style="background-image: url('http://git.reviewboard.kde.org/media/rb/images/review_request_box_top_bg.png'); background-position: left top; background-repeat: repeat-x; border: 1px black solid;">
<tr>
<td>
<div>Review request for Build System and KDEPIM-Libraries.</div>
<div>By Alex Merry.</div>
<p style="color: grey;"><i>Updated June 2, 2012, 11:20 p.m.</i></p>
<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;">Append, not prepend, items to CMAKE_MODULE_PATH
In KdepimLibsConfig.cmake, we previously prepended the cmake module path
to CMAKE_MODULE_PATH. This could interfere with projects that want to
override a FindFoo.cmake script from this location (eg: provided by some
KDE package) with one in their own source tree.
For example, it can break the build of Calligra which has a
FindMarble.cmake script that is incompatible with one provided by some
other KDE software.
(Question: why is this line even needed?)</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>KdepimLibsConfig.cmake.in <span style="color: grey">(8acbc6c0712f7536620226eb954edaf62b0d28da)</span></li>
</ul>
<p><a href="http://git.reviewboard.kde.org/r/105126/diff/" style="margin-left: 3em;">View Diff</a></p>
</td>
</tr>
</table>
</div>
</body>
</html>