On Thu, 6 Aug 2009, Michel Briand wrote:
Personally I've always seen interface as a contract. A contract between a library writer and library user.
The API is the compile-time contract and the ABI is the run-time contract.
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
This is supposed to make things easier.
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.
The goal is to allow libraries to be updated without needing to rebuild all applications which link against a library with that name. There is also a goal to allow incompatable libraries to live side by side so that applications which need different libraries can live on the same system.
Or I'm completely wrong.... but the documentation lacks some clues about what is this all about ;)))
Libtool did not invent these issues. Different operating systems provide varying capabilities and methods for dealing with library versions.
Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ _______________________________________________ http://lists.gnu.org/mailman/listinfo/libtool
