[CMake] 2.6.4: dependencies on imported targets work fine for libraries but not modules

[Alan W. Irwin]

On 2009-08-25 19:19-0700 Alan W. Irwin wrote:

Oops.  I had a screwup in the file dependencies for the project that was
importing PLplot libraries and modules.  Once that was solved touch ....
ps.so made the component of the project that file depended on the ps target
build fine.  Sorry for the noise about that.

However....

>
> One issue for the ps target is it has no
> IMPORTED_LINK_INTERFACE_LIBRARIES_NOCONFIG property set.  This is incorrect
> since that module depends on plplotd when it is built in the PLplot build.
> The completely analogous situation for plplotd is that library depends on
> both external (to PLplot) libraries as well as libraries like csirocsa that
> are built internally (by the PLPlot build).  All that is summarized in the
> above IMPORTED_LINK_INTERFACE_LIBRARIES_NOCONFIG property for plplotd. but
> the ps target (and many more that are built by PLplot where some of them
> even have external (to the PLplot build) dependencies) are totally missing
> IMPORTED_LINK_INTERFACE_LIBRARIES_NOCONFIG.
>
> What this issue will probably do is disrupt the proper flow of dependencies
> from plplotd to ps so if you touch the location corresponding to plplotd,
> then the parts of the build that depend exclusively on the ps target will
> not get rebuilt.  So that is probably a separate issue....

I tried testing a test_c_psc target that just file depended on the ps
target, and the above hypothesis is correct.  If I touch the location
corresponding to the ps target, the test_c_psc target gets rebuilt as
expected.  if I touch the location corresponding to the csirocsa target,
then that dependency propagates to the plplotd target as expected from the
corresponding plplotd IMPORTED_LINK_INTERFACE_LIBRARIES_NOCONFIG property
and everything that file depends exclusively on that plplotd target gets
rebuilt.  However, if I touch the location corresponding to the plplotd
library, the dependency does not propagate to the ps target (probably in
part due to its missing IMPORTED_LINK_INTERFACE_LIBRARIES_NOCONFIG
property), and the test_c_psc target that just file depended on the ps
target did not get rebuilt.

IMPORTED_LINK_INTERFACE_LIBRARIES_NOCONFIG isn't the whole story. If I hand
edit export_plplot-noconfig.cmake to add the line
IMPORTED_LINK_INTERFACE_LIBRARIES_NOCONFIG "plplotd" to the properties for
the ps target, then touching the plplotd location does not result in a
rebuild of the test_c_psc target.

For my use case (see below) this issue only matters from the perspective of
doing dependency tests with touch of files associated with imported module
targets.  The reason is that if I update something to do with the core
PLplot library (plplotd), then ps gets updated in the core as well (because
of the dependency there between the two) so that "make install" will update
files corresponding to both the plplotd and ps targets. Therefore, the
faulty dependencies in the export_plplot-noconfig.cmake for modules don't
matter for my use case, but they might matter for someone else's project. In
any case, I will follow guidance from the CMake developers about whether
they feel it is worth it to submit this issue to the bug tracker.

My use case is I have a project closely related to PLplot (in fact a build +
massive tests of the installed PLplot examples), and I would like
dependencies to flow cleanly from the PLplot core build to this related
project.  Ideally, if I update something in the PLplot source code and run
"make install" then only the relevant components of the install tree are
updated (that already happens), and when I re-run complete tests in the
installed examples tree, only those parts of the tests that are affected by
the updated PLplot components in the install tree are run.  I am now close
to that ideal case, but because touching stuff in the installed examples
doesn't always propagate as you would expect, I have to debug the remaining
dependency issues by touching core plplot source code to see how the
dependencies propagate to the installed examples build.

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 libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__________________________

Linux-powered Science
__________________________