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