[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.  But when I link to
> the library, the other files do get rebuilt.
>
> Example:
>
> lib/mod.cpp
> lib/mod2.cpp
> lib/mod3.cpp
> lib/lib/mod.h
> lib/lib/mod2.h
> lib/lib/mod3.h
>
> mod1.h:
> class mod {
> };
>
> mod2.h:
> #include "lib/mod1.h"
>
> class mod2 : public mod1 {
> };
>
> mod.cpp
> #include "lib/mod.h"
>
> mod2.cpp:
> #include "lib/mod2.h"
>
> // etc.
>
> So mod.h contains the base class, and mod2.h and mod3.h contain derived
> classes.  Changing mod.h requires all of the example source files above to
> be recompiled to be correct, but "make" in the lib directory only
> recompiles mod.cpp.
>
> If I have a program elsewhere which references this library, doing a "make"
> in its build directory causes dependency checks and results in mod2.cpp and
> mod3.cpp being recompiled as well as mod.cpp.
>
> The depend.mak and depend.internal files correctly list mod.h as being in
> the dependencies for mod2.o and mod3.o, but those rules don't appear to get
> used.
>
> Is this expected behavior?  Is there some way to change it to cause a
> "make" in the lib directory to compile all files dependent on the header,
> even if transitively (correct word?)?
>
> Thanks.  This is really throwing our developers for a loop as we transition
> from home-grown make to CMake.

Hi Chris:

I have used CMake for years, but I am still a naive user with respect
to such dependency tracker issues.  But my own personal opinion is the
transitive behaviour is the correct one so I am quite surprised this
is happening.

So my opinion is this is likely a bug for your particular platform. So
I strongly suggest you follow up with the list with more details
concerning your platform, e.g., what OS, what CMake version (including
whether you built it yourself or installed a binary version from
somewhere), which CMake generator (e.g., "Unix Makefiles", "MSYS
Makefiles", or whatever you used), which compiler, which compiler
version.  You may also want to try to build the absolutely latest
released version of CMake as well (if that is not what you are
currently using) to see if that changes anything.

>From the above you have obviously started down the road of making the
simplest possible example which exhibits the behaviour. I suggest you
finish such a mini-project and wrap that into a compressed tarball
that you attach to your post to the list.  That would allow others
here to conveniently confirm (or not) whether the dependency
tracker has this non-transitive issue with headers on their particular
platform.

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
__________________________