Joseph Garvin <joseph.h.gar...@gmail.com> - Wed, 5 Aug 2009 17:02:18 -0500
>On Wed, Aug 5, 2009 at 4:46 PM, Bruce Korb <bk...@gnu.org> wrote: > >> On Wed, Aug 5, 2009 at 2:32 PM, Joseph Garvin<joseph.h.gar...@gmail.com> >> 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. _______________________________________________ http://lists.gnu.org/mailman/listinfo/libtool
