[CMake] Avoiding a relink

[Brad King]

Philip Lowman wrote:
> I wasn't thinking of it in that context when I said that.  Yes, I think 
> you're correct and I've noticed that behavior before.  I usually work 
> around it with make foo/fast assuming foo is the shared library I'm 
> patching.
> 
> Not sure why CMake does what it does.  For the Makefile generator (at 
> least) it would seem that it would be fairly easy to avoid relinking 
> against a shared library that has only had it's implementation changed.  
> A special file could be outputted alongside the ".so" that if present 
> indicates that a header file changed and targets could depend on this 
> instead of the shared library itself to handle relinking.
> 
> There must be some corner case neither of us can't think of.  Perhaps 
> there is a way to break binary compatibility by modifying a cpp file? I 
> can't think of any.

Try removing an object file from a shared library, rebuild just that library,
and then run the executable (which still exists).  It will break at runtime,
but if you try relinking the executable it will fail at build time and the
executable will not exist anymore.

Also, it is possible that the executable's source files do manual extern
declarations instead of including header files.  Then the shared library
API can change and break the executable at runtime too.

-Brad