On Sat, 18 Oct 2025 at 01:22, David E. Wheeler <
david@justatheory.com> wrote:
>
> Adding Mankirat, who developed the ABI checker for his GSoC project.
Thanks!
Really interesting discussion.
On Sat, 18 Oct 2025 at 00:51, Peter Geoghegan <
pg@bowt.ie> wrote:
>
> On Fri, Oct 17, 2025 at 3:11 PM Nathan Bossart <
nathandbossart@gmail.com> wrote:
> > Anything else? I suppose this idea is entirely dependent on the
> > maintainers of the abi-compliance-check code to adapt to it, so we'll need
> > buy-in from them, too.
>
> That would require parsing the file and understanding that any
> compliance failures associated with a given commit should be
> suppressed. But that seems decidedly nontrivial to me. I can easily
> think of (admittedly somewhat contrived) scenarios where it's
> basically impossible to make this work due to transitive dependencies
> across commits.
>
> I suspect that any practical approach to solving this problem will
> have to involve ignore files that look somewhat like a Valgrind
> suppression file. It'll have to be based on symbol names, plus
> possibly a specific ABI breakage type.
The per-branch file containing the commit hash reference for that branch is a good solution and can be easily implemented since perl is really good at working with files.
But if we want a much clearer way based on symbol names, we could use a standard per branch suppression file, which the abidiff tool directly supports for this purpose[1].
For example, each branch could have an `abi.suppr` file with content like this:
# commit hash: 123456abc
[suppress_function]
name=stats_lock_check_privileges
# comments for this function
# commit hash: oldercommit345
[suppress_type]
type_kind = struct
name = some_struct_name
changed_data_members = updated_member_name
If needed, the contents of this file could be truncated on a new minor release maybe?
Added a patch for the same for handling current abi compliance failures on baza.
Regards,
Mankirat
