[CMake] Avoiding a relink

[Philip Lowman]

On Fri, Feb 27, 2009 at 2:32 PM, Jed Brown <jed at 59a2.org> wrote:

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


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.

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