On Fri, Jan 15, 2010 at 6:59 PM, Alexander Neundorf <a.neundorf-w...@gmx.net > wrote:
> On Friday 08 January 2010, Ryan Pavlik wrote: > > On Thu, Jan 7, 2010 at 4:00 PM, Jed Brown <j...@59a2.org> wrote: > > > On Thu, 07 Jan 2010 15:54:33 -0600, Ryan Pavlik <rpav...@iastate.edu> > > > > > > wrote: > > > > If you use the _LIBRARIES variable, you don't need to even mess > around > > > > with the imported targets thing > > > > > > Dumping recursive dependencies in *_LIBRARIES causes overlinking, they > > > should only be there when linking statically. > > > > > > Jed > > > > So then actually should we all be doing imported targets in our find > > modules then? I didn't realize it: most of the ones I looked at that > come > > In general, yes. > It's just that this feature is still relatively new (2 years now), and I > think > no existing Find-module has been converted. > In KDE we create and install such a file (but in KDE we create the libs > ourselves, so this is not what this thread here is about), but just last > week > I converted our (KDEs) copy of FindQt4.cmake to create imported targets for > the Qt libraries, so we finally get the optimized/debug libs handled > properly: > > http://websvn.kde.org/trunk/KDE/kdelibs/cmake/modules/FindQt4.cmake?view=log > > It seems to be working properly as it is now, and plan to merge this with > CMakes FindQt4.cmake soon. > > > with cmake didn't use it, so I just worked around it - wrote a function > > that can safely remove those dupes instead :) > > > > Is there any drawback (besides slightly longer code) to doing the > imported > > targets route? > > Most Find-modules can be included multiple times without problems, if you > create imported targets and include this file multiple times cmake > complains > that the (imported) target already exists. So you have to check in the > Find-module whether the imported target already exists > if(NOT TARGET Qt4ImportedTarget__QtCore) > ... > and handle the case properly. > > And I recommend then, having created the imported target, still to set the > normal cmake variable: > set(QT_QTCORE_LIBRARY Qt4ImportedTarget__QtCore) > so outside users will not notice that something has changed. > 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. 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. 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? TIA Adolfo > > To improve "diagnosability" of potential issues I also recommend to give > these > imported targets a clear prefix, to give users a hint what may be going on > in > in case of a problem they get a linker error like > "Could not find library -lQt4ImportedTarget__QtCore" > > This is much better as if they would get "Could not find library -lQtCore", > because this doesn't look like there might be anything special (like > imported > targets) involved in the issue. > > Alex > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Follow this link to subscribe/unsubscribe: > http://www.cmake.org/mailman/listinfo/cmake >
_______________________________________________ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
