[CMake] Avoiding a relink

Jed Brown jed at 59A2.org
Fri Feb 27 14:32:24 EST 2009


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.

Jed
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://www.cmake.org/pipermail/cmake/attachments/20090227/b362ac9c/attachment.pgp>


More information about the CMake mailing list