[CMake] Is this expected behavior?

[Chris Johnson]

Thanks for the reply and good advice, Alan.  Will do.

..chris

On Mon, Dec 8, 2014 at 2:58 PM, Alan W. Irwin <irwin at beluga.phys.uvic.ca>
wrote:

> 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
> __________________________
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20141208/c2493e62/attachment-0001.html>