<div class="gmail_quote">On Fri, Feb 27, 2009 at 2:32 PM, Jed Brown <span dir="ltr"><<a href="mailto:jed@59a2.org">jed@59a2.org</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><div></div><div class="Wj3C7c">On Fri 2009-02-27 20:26, Jed Brown wrote:<br>
> On Fri 2009-02-27 11:09, Bill O'Hara wrote:<br>
> > Lets say I have a CMakeLists.txt like this:<br>
> ><br>
> > add_library(foo STATIC foo.c bar.c)<br>
> > add_executable(test test.c)<br>
> > target_link_libraries(test foo)<br>
> ><br>
> > where test.c uses only functions defined in foo.c but not bar.c (assume some<br>
> > other target will use foo as well and use functions from both foo.c and bar.c).<br>
> ><br>
> > Is it possible to avoid the relink of test when foo is changed because of a<br>
> > change in bar.c? Just as an optimization to avoid unnecessary relinks to speed<br>
> > up the user experience?<br>
><br>
> I'm guessing this won't work because it requires very deep knowledge to<br>
> determine that nothing in bar.c is called, even transitively, through<br>
> foo.c.<br>
><br>
> What I'd like though is to not relink targets when a shared library<br>
> changes. That is, suppose libfoo is a shared library in the example<br>
> above. If relinking is required then a header must have changed so<br>
> 'test.c' would need to be recompiled. If no headers have changed, then<br>
> libfoo can be rebuilt and the executable 'test' does not need to be<br>
> rebuilt. Presumably there is a reason this isn't the default, what is<br>
</div></div> ^^^^^^^<br>
<br>
Should be 'relinked'. Philip says<br>
<div class="Ih2E3d"><br>
> Of course, CMake will still relink test on a regular "make" as it should.<br>
<br>
</div>Why should it? Shared libs are regularly updated on production machines<br>
without relinking the system. If the interface hasn't changed, why<br>
should CMake relink everything anyway.</blockquote><div><br>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><br></div></div>-- <br>Philip Lowman<br>