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

Stephen Kelly steveire at gmail.com
Tue Feb 26 03:46:23 EST 2013


Brad King wrote:

> On 2/25/2013 5:18 PM, Matthew Woehlke wrote:
>> 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.
> 
> These are all good examples.  Of course since CMake already does
> the safe thing people would not have hit these.
> 
> Steve, I think we should just leave CMAKE_LINK_DEPENDS_NO_SHARED
> as it is.  If you want that behavior by default in KDE then set
> it in a high-level project's package configuration file.

Fair enough. I'd reverted the branch already and now I've deleted it from 
stage. The unit test change is probably still useful, but would need a WIN32 
branch in the test and would need to figure out what happened to the mac 
dashboard I linked to before.

Thanks,

Steve.





More information about the cmake-developers mailing list