[CMake] What is the preferred method of handling inter-library dependencies?

[Alan W. Irwin]

On 2006-07-13 17:02-0400 Brad King wrote:

> William A. Hoffman wrote:
>> At 04:41 PM 7/13/2006, Alan W. Irwin wrote:
>>> How do I get access to the actual link flags used for the link command
>>> generated by cmake (which presumably includes all the appropriate -L and -l
>>> flags to access lib[xyz] and libexternal[12] as well as platform-dependent
>>> link flags).  I need those actual link flags to configure pkg-config files
>>> that describe how external applications should link to libx, liby, and libz.
>>
>> That is a harder question, which is why I ignored it... :)
>>
>> The information is not to hard to get at from c++, and some if it
>> is in the cache.  It may require some sort of new cmake built in command
>> to create pkg-config files.  Is anyone doing something like this?
>
> The set of link directories and libraries needed to use a package from
> its installation is not necessarily the same as that needed to build it
> in the first place.  The same goes for include directories.

>
> This information is computed by a few CMake projects in order to provide
> packaging files, though not pkg-config specifically.  Basically you have
> to keep track of what include directories, link directories, and
> libraries come from 3rd party (outside your project) tools and list them
> separately.  Then add to the list the locations to which you install
> your project.

I believe you need more information than -L and -l options; you also need to
know the special link options that are required (for rpath, shared versus
static, bundle or whatever) on the particular platform that is being used
for the build.

Bill mentioned above the possibility of making something specific to
pkg-config, but I think I prefer the following approach instead: I would
like GET_TARGET_PROPERTY to have the option to deliver back the exact and
complete compile flags and link flags (for the install location in the rpath
case) that CMake uses to build that target on the build platform.  Once that
information is available to cmake users, it is completely straightforward to
use it to configure packaging files of _any_ type including pkg-config ones.

It sounds like this is a CMake wish-list item, but I hope the CMake
developers give it high priority because most package developers do like to
provide packaging files so their users don't have to struggle with compiling
and linking applications that use the package in question.

If my wishlist plea has inspired any CMake developer here to extend
GET_TARGET_PROPERTY appropriately, I would be very glad to help out by
testing the results. PLplot is an excellent test bed for that.  It's large
enough to be non-trivial (9 different libraries built and installed with
various dependencies between them), but small enough (10-minute builds) to
get testing done fairly quickly.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the Yorick front-end to PLplot (yplot.sf.net); the
Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__________________________

Linux-powered Science
__________________________