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. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers