[CMake] intercomponent link dependencies?

[Adolfo Rodríguez Tsouroukdissian]

On Fri, Jan 15, 2010 at 6:59 PM, Alexander Neundorf <a.neundorf-work at gmx.net
> wrote:

> On Friday 08 January 2010, Ryan Pavlik wrote:
> > On Thu, Jan 7, 2010 at 4:00 PM, Jed Brown <jed at 59a2.org> wrote:
> > > On Thu, 07 Jan 2010 15:54:33 -0600, Ryan Pavlik <rpavlik at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20100120/0b9d1a2e/attachment.htm>