[cmake-developers] Should CMAKE_LINK_DEPENDS_NO_SHARED be on by default?

[Matthew Woehlke]

On 2013-02-25 15:02, Brad King wrote:
> Can you elaborate on some of the theoretical cases where relinking
> will be needed but no header files have changed?  It would be useful
> to have them available for discussion.

The possibility that first came to mind is where the API depends on 
compiler flags or similar preprocessor-ish bits, especially if these are 
not well guarded with something like a configured config.h to change 
when these change (and ensure that users get the same imports as what 
was built).

For example, turning PIC on/off, changing the language support level, 
etc. might cause the API to change in a way that is not reflected in the 
headers (especially language support level, since most projects don't 
check for that... although conversely one can also hope that wouldn't 
cause an API break...).

A slightly contrived example would be if you are relying on other than 
the CMake default-defined symbol to detect when your own library is 
being built, and forget to define it (or accidentally undefine it), such 
that all of the sudden there is a large change in your export set.

Another example is running a system upgrade across a mass rebuild, such 
that system libraries are suddenly linked with a different compiler 
version than before. Depending on what else has changed, and how the 
system package manager works, I could see that this *might* not cause 
the time stamps on the header files to change.

I wasn't thinking of it, but the example by dlrdave is also a good one, 
and in my experience not all that wildly unusual... only applies to 
lazy-resolving platforms, however (i.e. not Windows).

To some extent, I suppose it comes down to how one weighs correctness 
versus speed. For most projects, the speed hit is probably small, so I'd 
be inclined to favor correctness, and recommend large projects that know 
that the cost for them is unusually high to override the choice.

-- 
Matthew