[gnutls-devel] GnuTLS | Drop lib{gnutls, dane}-latest-x86_64.abi from the repo (#954)

[Development of GNU's TLS library]

Daiki Ueno created an issue: https://gitlab.com/gnutls/gnutls/-/issues/954



When adding a new API function, one biggest pain point is updating `lib{gnutls,dane}-latest-x86_64.abi` files, because the output of `abidw` is not stable and information that relies on the current build environment is emitted, e.g., `comp-dir-path='/home/nmav/cvs/gnutls-mine/lib'`.

Interestingly, `abidiff` only takes into account of the existence of `elf-symbol` (ignores type changes). So one can cheat `abi-check` by manually adding an `elf-symbol` entry for the new function: [example 2](623058337490b847d27b736c67b6e710efb980a7), [example 1](6037706541616cfd2d4b49f6f5939ce6dddd1a53). That means, there is not much sense to maintain `lib{gnutls,dane}-latest-x86_64.abi`, as we already have `devel/symbols.last`.

Therefore I propose:
- drop `lib{gnutls,dane}-latest-x86_64.abi` and check against it (keep `lib{gnutls,dane}-$(VERSION)-x86_64.abi`
- maintain the output of `abidiff` from the previous `lib{gnutls,dane}-$(VERSION)-x86_64.abi` in the repository, say `lib{gnutls,dane}-x86_64.abidiff`
- add an instruction to update `lib{gnutls,dane}-$(VERSION)-x86_64.abi` and clear `lib{gnutls,dane}-x86_64.abidiff` at release time

This not only makes `make file-updates` reliable, but also tightens the check as it covers type changes.

Thoughts?

-- 
Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/954
You're receiving this email because of your account on gitlab.com.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnutls-devel/attachments/20200314/7f1f6982/attachment-0001.html>