[cmake-developers] cmake build does too much work

[Ben Boeckel]

On Wed, Dec 11, 2013 at 17:13:00 -0500, Matthew Woehlke wrote:
> 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.

While the tool I posted in the other message is a possibility, how would
you deal with inline functions changing? Same with template
implementations? For example, when a Boost *header* changes,
dependencies need to be recompiled to get the new inline code.

Which build systems actually have that level of granularity? Does XCode
or VS track external dependencies on the file level? I don't *think*
make and ninja do so, since after a GCC upgrade, my trees don't all of a
sudden do a full rebuild (and after upgrading from Fedora N to N+1,
nuking build trees is usually on the menu due to new soversions of
libraries shifting around; a simple rebuild misses this).

--Ben