That's the problem. We don't have abi-check automated yet. Although we
don't have to limit ourselves to that.
What we do have is regular ABI breaks landing and nobody noticing. So I
audit the code manually and propose the missing breaks. Fortunately the
whole team is getting on board and noticing them more often, but it's
still not automated.
On 27/08/15 11:26, Christopher James Halse Rogers wrote:
On Thu, Aug 27, 2015 at 12:05 PM, Daniel van Vugt
<daniel.van.v...@canonical.com> wrote:
That's true. If someone adds a field to a struct or changes the size
of a bool, symbol names don't change. Even worse; how do you
communicate that myprojectN uses libstdc++M? In a past life I actually
went to the trouble of putting out different binary releases for libc5
systems vs libc6. So another hidden part of your ABI is "what other
C/C++ library ABIs does it depend on?".
What I've been suggesting however is aimed at solving precisely the
kind of ABI break that mir-team keeps landing and reviewers not noticing.
I'm not entirely sure what problem you're trying to solve here? We
regularly break - and bump - ABIs, and that's fine.
We *also* have the abi-check target which is strictly better than
symbols.map at finding these things - it also finds structure size
changes and enumeration numbering differences, for example.
We've talked about having abi-check run as an advisory test on all MPs
for a while. Now that JaaS is mostly here, maybe that would solve the
problem?
--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/mir-devel
