Re: libtool versioning and ABI

[Michel Briand]

Joseph Garvin <address@hidden> - Wed, 5 Aug 2009 17:02:18
-0500

>On Wed, Aug 5, 2009 at 4:46 PM, Bruce Korb <address@hidden> wrote:
>
>> On Wed, Aug 5, 2009 at 2:32 PM, Joseph Garvin<address@hidden>
>> wrote:
>> > I read a description of libtool's versioning here:
>> >
>> >
>> http://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html
>> >
>> > What's confusing to me is that this way of handling versioning doesn't
>> seem
>> > to pay attention to ABI. It mentions bumping numbers for interface
>> changes
>> > (API) but not for changing size of data structures, editing the contents
>> of
>> > inline functions, etc.
>>
>> Those surely sound like rule 4 to me:
>> > If any interfaces have been added, removed, or changed since
>> > the last update, increment current, and set revision to 0.
>>
>> changing structures or funtional interfaces (inline functions),
>> surely is an interface change.
>
>
>From an OOP standpoint private members are hidden implementation details,
>and aren't usually considered to be part of the 'interface' (public members
>and member functions) to a class, thus my confusion. Different community,
>different parlance.
>
>... But that still doesn't make sense. If I only add (don't remove functions
>or change existing signatures) to my interfaces, I still bump the current
>number according to that rule. But adding to an interface doesn't
>necessarily break ABI. So if current-bumps indicate ABI changes, I'm telling
>people ABI has broken when it actually hasn't. I don't understand.

Personally I've always seen interface as a contract.
A contract between a library writer and library user.

Why does libtool want to interfere with this ... has always made me
scratching my head....

Since it's a contract, ABI changes fall into the contract agreement. So
why bother with complex versionning and error-prone version
manipulations with substraction

The difficult, and somehow messy, scheme of libtool versioning is
boring and uneasy : developers do not understand this different way
that overlap with the classical, natural and contractual scheme (X.Y.Z
that one can still use with the -release flag) ; and this create
additional work to handle package version (official, classical) in
parallel with libtool -version-info scheme.

Or I'm completely wrong.... but the documentation lacks some clues
about what is this all about ;)))

My 2 cents.