[CMake] Is this expected behavior?

[Alan W. Irwin]

On 2014-12-08 12:53-0600 Chris Johnson wrote:

> When I change a header file for a library, and then do a "make" in the
> build directory, only source (C++) files which directly include that header
> get rebuilt, but those which use it indirectly do not.

Hi Chris:

For one of my C projects (ephcom) I cannot confirm this behaviour on
Linux (Debian Stable); using CMake-3.0.2 (which I built myself from
source using the boostrap method); using the "Unix Makefiles"
generator; and using gcc (Debian 4.7.2-5) 4.7.2.  I also use ccache,
but I don't think it is relevant because all that means is if you are
rebuilding something exactly (no source changes and no option changes)
it will be very fast.  But you will actually see that ccache command
being executed if CMake thinks a rebuild is necessary, and otherwise
not.

Here is the relevant layout of the source and header files of
the ephcom_spice library:

The complete source code for the ephcom_spice library:
ephcom/src/libs/ephcom_spice.c

The relevant headers:

software at raven> grep include ephcom/src/libs/ephcom_spice.c \
> ephcom/src/include/ephcom_spice.h
ephcom/src/libs/ephcom_spice.c:#include <stdio.h>
ephcom/src/libs/ephcom_spice.c:#include <stdlib.h>
ephcom/src/libs/ephcom_spice.c:#include <string.h>
ephcom/src/libs/ephcom_spice.c:#include <errno.h>
ephcom/src/libs/ephcom_spice.c:#include <math.h>
ephcom/src/libs/ephcom_spice.c:#include "ephcom_spice.h"
ephcom/src/libs/ephcom_spice.c:#include "ephcom.h"
ephcom/src/libs/ephcom_spice.c:#include "gnulliver.h"
ephcom/src/include/ephcom_spice.h:#include <stdio.h>
ephcom/src/include/ephcom_spice.h:#include "ephcomdll.h"
ephcom/src/include/ephcom_spice.h:#include "ephcom.h"

So I think from your above description that ephcomdll.h qualifies as
an indirectly used header. However, if I touch
ephcom/src/include/ephcomdll.h, the ephcom_spice library always
rebuilds meaning I cannot confirm your reported behaviour.  Note this
is a complex example (the ephcom_spice library depends on other
libraries in the same source tree which may be dictating the rebuild
behaviour), but also note that none of them depend directly on
ephcomdll.h as illustrated by the following empty results:

software at raven> grep ephcomdll.h ephcom/src/libs/*.[ch]

So it is a fairly clean counterexample, and I am glad to hear from your
subsequent post that you will be attempting to define a complete
simple project that demonstrates the non-transitive header dependency
tracker issue you have found on your platform with a much more
complex project.

By the way, generating those simple projects to illustrate a CMake
issue is extremely helpful in one other way.  Whenever, I do that I
usually (~80 per cent of the time) find there is no "CMake issue" that
I can replicate in the simple example, and the problem is actually a
misuse of CMake (e.g., wrong library dependencies) in my complex "real
world" example.  :-)

So good luck figuring this out, and there is certainly no shame if it
turns out to be the latter case.  However, if it is the former case,
then it will be interesting to see if the CMake dependency tracker
issue demonstrated by your complete simple project on your platform
occurs on my and other's platforms as well.

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); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); 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
__________________________