<div class="gmail_quote">On Fri, Feb 27, 2009 at 5:24 PM, Brad King <span dir="ltr"><<a href="mailto:brad.king@kitware.com" target="_blank">brad.king@kitware.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div>Philip Lowman wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
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.<br>
<br>
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.<br>
<br>
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.<br>
</blockquote>
<br></div>
Try removing an object file from a shared library, rebuild just that library,<br>
and then run the executable (which still exists). It will break at runtime,<br>
but if you try relinking the executable it will fail at build time and the<br>
executable will not exist anymore.</blockquote><div><br>Good point, although this could also be handled by forcing a relink against the .so when adding or removing files from add_library().<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Also, it is possible that the executable's source files do manual extern<br>
declarations instead of including header files. Then the shared library<br>
API can change and break the executable at runtime too.</blockquote><div><br>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.<br>
<br>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.<br>
</div></div><br>-- <br>Philip Lowman<br>