tis 2023-03-07 klockan 14:20 +0100 skrev Bruno Haible: > Simon Josefsson wrote: > > Consider adjusting your habit to update the libtool version > > directly > > AFTER a release instead. I put the following in cfg.mk to make > > sure I > > don't forget this: > > > > sc_libtool_version_bump: > > @git diff v$(PREV_VERSION).. | grep '^+AC_SUBST(LT' > > > /dev/null > > > > Of course, you still have to bump it if you make any API/ABI > > changes, > > Is a maintainer not _more_ likely to forget about the libtool > versioning, when he has a rule like that, that makes him think "I'm > already on the safe side, since I have done it already"?
Yes, maybe -- although but approaches are fragile and depend on maintainer attention, so they are both sub-optimal. I have used libabigail's abidiff to find API/ABI differences with good results -- however, I don't know of a good way to check libtool shared library versionining information against it. Some brain storming how it would work: 1) On 'make check' (or distcheck, or similar), do a abidiff of the newly built library against a previously stored *.abi file and exit with failure on differences (or if no file exists). 2) Add README notes to instruct maintainers to add known good new *.abi files named like libfoo-x86_64-1-2-3.abi where 1-2-3 is the libtool- version when any API/ABI-changes are made, or when libtool version is bumped. Maybe the '-3' part shouldn't be part of the filename. 3) for bonus points: Add some consistency check that the diff follows libtool-semantics for ADDED vs MODIFIED ABI differences. Not all API/ABI changes results in abidiff-changes, though, although these days I think it is generally considered a bad idea to bump libtool shared library version for anything but pure symbol changes. For semantical changes, introduce new APIs and deprecate the old ones instead. /Simon
signature.asc
Description: This is a digitally signed message part
