[cmake-developers] cmake build does too much work

Matthew Woehlke matthew.woehlke at kitware.com
Wed Dec 11 17:13:00 EST 2013


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.)

-- 
Matthew




More information about the cmake-developers mailing list