[CMake] Avoiding a relink

[Philip Lowman]

On Fri, Feb 27, 2009 at 5:24 PM, Brad King <brad.king at kitware.com> wrote:

> 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.


Good point, although this could also be handled by forcing a relink against
the .so when adding or removing files from add_library().


> 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.


You make a good point about the extern case.  Although I've never used this
technique before I'm sure there is source code out here that does it.

So, is the idea worth logging as a feature request as an opt-in behavior?
It does seem like it would only be something CMake could easily control with
the Makefile generator.  On the whole I could see this being very useful for
projects that have lots of shared libraries or plugins, however.

-- 
Philip Lowman
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20090301/4b5f14c0/attachment.htm>