<br><br><div class="gmail_quote">On Fri, Jan 15, 2010 at 6:59 PM, Alexander Neundorf <span dir="ltr"><<a href="mailto:a.neundorf-work@gmx.net">a.neundorf-work@gmx.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">On Friday 08 January 2010, Ryan Pavlik wrote:<br>
> On Thu, Jan 7, 2010 at 4:00 PM, Jed Brown <<a href="mailto:jed@59a2.org">jed@59a2.org</a>> wrote:<br>
> > On Thu, 07 Jan 2010 15:54:33 -0600, Ryan Pavlik <<a href="mailto:rpavlik@iastate.edu">rpavlik@iastate.edu</a>><br>
> ><br>
> > wrote:<br>
> > > If you use the _LIBRARIES variable, you don't need to even mess around<br>
> > > with the imported targets thing<br>
> ><br>
> > Dumping recursive dependencies in *_LIBRARIES causes overlinking, they<br>
> > should only be there when linking statically.<br>
> ><br>
> > Jed<br>
><br>
> So then actually should we all be doing imported targets in our find<br>
> modules then? I didn't realize it: most of the ones I looked at that come<br>
<br>
</div>In general, yes.<br>
It's just that this feature is still relatively new (2 years now), and I think<br>
no existing Find-module has been converted.<br>
In KDE we create and install such a file (but in KDE we create the libs<br>
ourselves, so this is not what this thread here is about), but just last week<br>
I converted our (KDEs) copy of FindQt4.cmake to create imported targets for<br>
the Qt libraries, so we finally get the optimized/debug libs handled<br>
properly:<br>
<a href="http://websvn.kde.org/trunk/KDE/kdelibs/cmake/modules/FindQt4.cmake?view=log" target="_blank">http://websvn.kde.org/trunk/KDE/kdelibs/cmake/modules/FindQt4.cmake?view=log</a><br>
<br>
It seems to be working properly as it is now, and plan to merge this with<br>
CMakes FindQt4.cmake soon.<br>
<div class="im"><br>
> with cmake didn't use it, so I just worked around it - wrote a function<br>
> that can safely remove those dupes instead :)<br>
><br>
> Is there any drawback (besides slightly longer code) to doing the imported<br>
> targets route?<br>
<br>
</div>Most Find-modules can be included multiple times without problems, if you<br>
create imported targets and include this file multiple times cmake complains<br>
that the (imported) target already exists. So you have to check in the<br>
Find-module whether the imported target already exists<br>
if(NOT TARGET Qt4ImportedTarget__QtCore)<br>
...<br>
and handle the case properly.<br>
<br>
And I recommend then, having created the imported target, still to set the<br>
normal cmake variable:<br>
set(QT_QTCORE_LIBRARY Qt4ImportedTarget__QtCore)<br>
so outside users will not notice that something has changed.<br></blockquote><div><br>One question regarding the cmake convenience variables one exposes. Say that I'm migrating a very simple FindFOO.cmake script from "module" to "config" mode. This script only looks for one library, one headers directory, and exposes to the user FOO_FOUND, FOO_INDLUDE_DIRS and FOO_LIBRARIES. <br>
<br>In "module" mode, the user can also interact with the FOO_INCLUDE_DIR and FOO_LIBRARY (advanced) cache variables created by calls to find_path and find_library.<br>As far as I understand, in "config" mode, these two cache variables no longer need to exist (because foo-config.cmake sets them without requiring cmake to find the headers/lib location). Indeed, I'm currently no longer exposing them, so my question is: is this the recommended practice?<br>
<br>TIA<br><br>Adolfo<br><br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
To improve "diagnosability" of potential issues I also recommend to give these<br>
imported targets a clear prefix, to give users a hint what may be going on in<br>
in case of a problem they get a linker error like<br>
"Could not find library -lQt4ImportedTarget__QtCore"<br>
<br>
This is much better as if they would get "Could not find library -lQtCore",<br>
because this doesn't look like there might be anything special (like imported<br>
targets) involved in the issue.<br>
<br>
Alex<br>
<div><div></div><div class="h5">_______________________________________________<br>
Powered by <a href="http://www.kitware.com" target="_blank">www.kitware.com</a><br>
<br>
Visit other Kitware open-source projects at <a href="http://www.kitware.com/opensource/opensource.html" target="_blank">http://www.kitware.com/opensource/opensource.html</a><br>
<br>
Please keep messages on-topic and check the CMake FAQ at: <a href="http://www.cmake.org/Wiki/CMake_FAQ" target="_blank">http://www.cmake.org/Wiki/CMake_FAQ</a><br>
<br>
Follow this link to subscribe/unsubscribe:<br>
<a href="http://www.cmake.org/mailman/listinfo/cmake" target="_blank">http://www.cmake.org/mailman/listinfo/cmake</a><br>
</div></div></blockquote></div>