[cmake-developers] cmake build does too much work

[Matthew Woehlke]

On 2013-12-11 19:21, Ben Boeckel wrote:
> 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?

I don't think this is relevant? In these cases, a header is changing, 
which will (hopefully) lead to the source files using that header being 
rebuilt, which will cause the library to relink anyway. (And if the 
sources *aren't* rebuilt, I don't think relinking will help?)

Whether or not the sources of library B have correct dependencies on the 
headers of library A is, I believe, orthogonal to this problem, which is 
*only* about link-level dependencies. IOW the only rule affected would 
be 'libb.so: liba.so'.

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

I would expect the behavior for external dependencies would not change; 
they would either trigger rebuilds or not the same as they do currently. 
(Since of course we cannot rely on having 'ABI stamp files' for any 
external libraries...)

I'm *mainly* having problems within a single CMake project, which is 
what this would affect. It might have some downstream effect due to 
fewer libraries within the project changing to trigger downstream 
rebuilds, but that would be more incidental.

-- 
Matthew