<div dir="ltr"><div class="gmail_default" style="font-family:courier new,monospace">Thanks for the reply and good advice, Alan.  Will do.</div><div class="gmail_default" style="font-family:courier new,monospace"><br></div><div class="gmail_default" style="font-family:courier new,monospace">..chris</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Dec 8, 2014 at 2:58 PM, Alan W. Irwin <span dir="ltr"><<a href="mailto:irwin@beluga.phys.uvic.ca" target="_blank">irwin@beluga.phys.uvic.ca</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 2014-12-08 12:53-0600 Chris Johnson wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
When I change a header file for a library, and then do a "make" in the<br>
build directory, only source (C++) files which directly include that header<br>
get rebuilt, but those which use it indirectly do not.  But when I link to<br>
the library, the other files do get rebuilt.<br>
<br>
Example:<br>
<br>
lib/mod.cpp<br>
lib/mod2.cpp<br>
lib/mod3.cpp<br>
lib/lib/mod.h<br>
lib/lib/mod2.h<br>
lib/lib/mod3.h<br>
<br>
mod1.h:<br>
class mod {<br>
};<br>
<br>
mod2.h:<br>
#include "lib/mod1.h"<br>
<br>
class mod2 : public mod1 {<br>
};<br>
<br>
mod.cpp<br>
#include "lib/mod.h"<br>
<br>
mod2.cpp:<br>
#include "lib/mod2.h"<br>
<br>
// etc.<br>
<br>
So mod.h contains the base class, and mod2.h and mod3.h contain derived<br>
classes.  Changing mod.h requires all of the example source files above to<br>
be recompiled to be correct, but "make" in the lib directory only<br>
recompiles mod.cpp.<br>
<br>
If I have a program elsewhere which references this library, doing a "make"<br>
in its build directory causes dependency checks and results in mod2.cpp and<br>
mod3.cpp being recompiled as well as mod.cpp.<br>
<br>
The depend.mak and depend.internal files correctly list mod.h as being in<br>
the dependencies for mod2.o and mod3.o, but those rules don't appear to get<br>
used.<br>
<br>
Is this expected behavior?  Is there some way to change it to cause a<br>
"make" in the lib directory to compile all files dependent on the header,<br>
even if transitively (correct word?)?<br>
<br>
Thanks.  This is really throwing our developers for a loop as we transition<br>
from home-grown make to CMake.<br>
</blockquote>
<br></div></div>
Hi Chris:<br>
<br>
I have used CMake for years, but I am still a naive user with respect<br>
to such dependency tracker issues.  But my own personal opinion is the<br>
transitive behaviour is the correct one so I am quite surprised this<br>
is happening.<br>
<br>
So my opinion is this is likely a bug for your particular platform. So<br>
I strongly suggest you follow up with the list with more details<br>
concerning your platform, e.g., what OS, what CMake version (including<br>
whether you built it yourself or installed a binary version from<br>
somewhere), which CMake generator (e.g., "Unix Makefiles", "MSYS<br>
Makefiles", or whatever you used), which compiler, which compiler<br>
version.  You may also want to try to build the absolutely latest<br>
released version of CMake as well (if that is not what you are<br>
currently using) to see if that changes anything.<br>
<br>
>From the above you have obviously started down the road of making the<br>
simplest possible example which exhibits the behaviour. I suggest you<br>
finish such a mini-project and wrap that into a compressed tarball<br>
that you attach to your post to the list.  That would allow others<br>
here to conveniently confirm (or not) whether the dependency<br>
tracker has this non-transitive issue with headers on their particular<br>
platform.<br>
<br>
Alan<br>
__________________________<br>
Alan W. Irwin<br>
<br>
Astronomical research affiliation with Department of Physics and Astronomy,<br>
University of Victoria (<a href="http://astrowww.phys.uvic.ca" target="_blank">astrowww.phys.uvic.ca</a>).<br>
<br>
Programming affiliations with the FreeEOS equation-of-state<br>
implementation for stellar interiors (<a href="http://freeeos.sf.net" target="_blank">freeeos.sf.net</a>); the Time<br>
Ephemerides project (<a href="http://timeephem.sf.net" target="_blank">timeephem.sf.net</a>); PLplot scientific plotting<br>
software package (<a href="http://plplot.sf.net" target="_blank">plplot.sf.net</a>); the libLASi project<br>
(<a href="http://unifont.org/lasi" target="_blank">unifont.org/lasi</a>); the Loads of Linux Links project (<a href="http://loll.sf.net" target="_blank">loll.sf.net</a>);<br>
and the Linux Brochure Project (<a href="http://lbproject.sf.net" target="_blank">lbproject.sf.net</a>).<br>
__________________________<br>
<br>
Linux-powered Science<br>
__________________________<br>
</blockquote></div><br></div>