[CMake] xyz_LIBRARIES

[Adam Rankin]

Ok, that makes sense to me. What I’m seeing though, is that find modules and xyzConfig files for some software packages do not make a variable available that contains just target names. Xyz_LIBRARIES contains full path file locations.

This is my immediate frustration with leptonica for example. The config file it creates does not output a list of targets, and even if it did, it doesn’t dynamically build the list of targets depending on what dependencies it finds (libpng, libjpeg, etc…)

I think I will fork and rewrite the leptonica cmake file to properly expose target names.

Thanks,
Adam

From: Craig Scott [mailto:audiofanatic at gmail.com]
Sent: Wednesday, February 03, 2016 4:26 PM
To: Adam Rankin <arankin at robarts.ca>
Cc: cmake at cmake.org
Subject: Re: [CMake] xyz_LIBRARIES



On 4 February 2016 at 04:45, Adam Rankin <arankin at robarts.ca<mailto:arankin at robarts.ca>> wrote:
Hello all,

I am trying to sort out a project with multiple layers of dependencies and I am trying to figure out the “right” way of configuring things.

First easy question: Should a value xyz_LIBRARIES contain target names, or library file locations?

Preferably target names, assuming you mean imported targets (see answer to next question).


 Second question: Should a FindXYZ.cmake file add imported targets, or should a USE_xyz variable be created for later inclusion? (what if the project does not export its targets?)

Imported targets will be better for end users/developers. An imported target can provide not just the library file location, it can also provide other dependencies such as dependent libraries that also must be linked, header search paths, etc. Furthermore, with an imported target you can explicitly control what other targets are affected by these dependencies simply by linking against your imported target. If you chose the USE_xyz variable + include approach, then the include file will typically end up calling  link_libraries(), link_directories() and/or include_directories() commands and making those things apply to all targets defined thereafter, which used to be the norm but is no longer necessary with all the target_xxx() commands added in more recent versions of CMake (well, 2.8.11 or later).


 Third question: How’s your day going today?

Ask me again after the coffee kicks in. :P


--
Craig Scott
Melbourne, Australia
http://crascit.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20160203/c0e5dfc5/attachment.html>