On 2013-12-11 17:13, 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.)

FYI, the ninja folks mentioned that GYP already does this for Linux/Mac/Win... maybe we (CMake) could borrow their work?

--
Matthew

--

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

Reply via email to