On 12/11/2013 5:13 PM, Matthew Woehlke wrote:
I've been working on a project lately that isn't *that* massively large,
but has an unusually high number of library and executable targets. One
thing that's been bugging me is that any trivial change in a "lower
level" library causes more than a hundred targets to be relinked, for no
good reason I know of.
Now, I *do* get that relinking is good if the library ABI changes.
However, that's not the case here, and I am wondering if it would be
possible for CMake to generate an additional, intermediary step after
library linking to somehow export a file representing the ABI of the
library (with overwrite checks to not modify the file if the ABI has not
changed), and to use *those*, rather than the actual libraries, as the
dependencies for targets linking to the libraries. I think this could
produce a significant speed-up for incremental builds in some cases, as
it would allow the build to short-circuit the relink of many targets
when it turns out a library's ABI has not changed.
Does this sound like something CMake could/should do?
(I'm thinking something like running objdump on the resulting library
with suitable arguments and doing a copy_if_different on the output. I
guess this would only apply to shared libraries, and probably should be
an optional feature.)
There is this property:
http://www.cmake.org/cmake/help/git-master/variable/CMAKE_LINK_DEPENDS_NO_SHARED.html
If you wanted to use that for your project I think you can just run
cmake -DCMAKE_LINK_DEPENDS_NO_SHARED=TRUE.
The other option sounds interesting but hard to implement in a cross
platform manner.
-Bill
--
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
