[CMake] dependencies on system include files

Roger Leigh rleigh at codelibre.net
Tue Dec 18 07:34:38 EST 2018


On 17/12/2018 15:37, David Blaikie wrote:
> On Sun, Dec 16, 2018, 4:24 PM Kris Thielemans 
> <kris.f.thielemans at gmail.com <mailto:kris.f.thielemans at gmail.com> wrote:
> 
>     I’ve just had a problem caused by an upgrade of my system files (in
>     this particular case: boost). Rebuilding our software didn’t
>     correctly rebuild those files that depend on the updated boost
>     files. (I’m using CMake 3.9 with make on Ubuntu 16.04)____
> 
>     Checking a bit more carefully it appears that the system .h files
>     are not included in depend.make. I guess this is done to save some
>     time checking all those dependencies as system files are supposed to
>     be relatively stable, but if they’re not, it creates trouble of
>     course.
> 
>     Is there any way to change this behaviour? (ideally something like
>     for one time only, check if dependent system include files are more
>     recent then what was compiled, but that’s a stretch of course).____

 > If you're willing to run a different command or flag when rebuilding
 > after upgrading system libraries, I would guess the thing to do would be
 > to do a clean and rebuild, perhaps?

This is unfortunately insufficient.  After upgrading any system 
libraries you will have to clean everything, including the CMake cache, 
and re-run CMake from a clean build tree, then rebuild everything.

The reason for this is that the cache contains the results of 
find_library etc., and these may have changed as a result of the system 
upgrade.  However, the cached values may be used despite this.  It's 
safest to start from a clean slate.

For example, if you upgraded boost from 1.6x to 1.69 Boost.Filesystem 
dropped its dependency upon Boost.System, which is no longer a library 
(it's header-only).  This would result in a link failure.  I've not 
specifically tested this case to see if it would cope, but there is 
plenty of stuff cached which could potentially cause problems, and the 
solution to drop the cache is simple.  I wouldn't want to risk the 
integrity of the build due to the potential for subtle inconsistency 
between the cache and the system.  After you've upgraded the system, 
it's essentially a different system.


Regards,
Roger


More information about the CMake mailing list