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

[Alan W. Irwin]

Suppose in the same project I am building 3 different shared libraries where
libx has symbols resolved by liby (but not by libz), and liby has symbols
resolved by libz, and libz has symbols resolved by libexternal1 and
libexternal2.  So libx depends on liby (but not libz or the external
libraries), liby depends
on libz (but not the external libraries), and libz depends on the external
libraries.

What are the preferred entries for TARGET_LINK_LIBRARIES?

"Minimal dependencies", i.e.,
TARGET_LINK_LIBRARIES(x y)
TARGET_LINK_LIBRARIES(y z)
TARGET_LINK_LIBRARIES(z external1 external2)
?

Or "Mention all downstream library dependencies", i.e.,

TARGET_LINK_LIBRARIES(x y z external1 external2)
TARGET_LINK_LIBRARIES(y z external1 external2)
TARGET_LINK_LIBRARIES(z external1 external2)

?

For the alternative libtool approach, you are encouraged to specify just the
minimal set of library dependencies to libtool, and it figures out the rest
depending on platform, but I need to know about what CMake recommends for
this situation in a multi-platform environment?

A supplementary question is how can I discover from the CMake environment
the exact set of linker options and compile options used to build a library
for a particular platform? I need this information to configure pkg-config
*.pc files that describe the required link flags and compile flags for each
of the libraries that are built as part of my project.  I tried using 
GET_TARGET_PROPERTY with either LINK_FLAGS or COMPILE_FLAGS, but in both
cases I got NOTFOUND as the response (for CMake-2.4.2 on Linux).  Of course,
I have the option of accumulating the compile flags used for the sources for
each library, and keeping track of what is specified to
TARGET_LINK_LIBRARIES, but in the latter case especially I am concerned that
the actual link flags generated by CMake will be much more extensive than
what I specify to TARGET_LINK_LIBRARIES.  For example, there is the
inter-library dependency case discussed above, rpath related stuff, and
additional platform-dependent linker options that CMake might generate on
its own.

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
__________________________