On Wed, Dec 11, 2013 at 19:38:21 -0500, Matthew Woehlke wrote:
> 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?)
I'm concerned about this:
(external) (internal)
template.hpp <-- A.cpp --> header.h
^ ^
| |
| \- liba.so
| ^
| |
\-- B.cpp <-- libb.so
Where template.hpp changes (testing with 2.8.12.1 shows that touching
template.hpp triggers a rebuild with Ninja, but not Unix Makefiles),
internal_header.h changes and A.cpp gets recompiled, liba.so relinked
and libb.so skipped because the ABI hasn't changed. The problem is that
if something inlined from template.hpp is incompatible with what B.cpp
has inlined, things need recompiled.
I don't know how other tools work, but Unix Makefiles are certainly
popular enough that I'd like to see that this cannot cause problems
first. Of course, the fix may be to have A.cpp depend on template.hpp
directly. I don't know the cost of this in for the build or generate
time (but possibly noticable with files which include a lot).
> 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...)
Maybe the problem I was referencing was out-of-scope. I wonder if
abi-compliance-checker handles mismatches between inlined symbols
(mostly a problem outside of -fvisibility=hidden).
--Ben
--
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
