[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