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
