On 08/05/11 14:20, Harald Welte wrote:
Hi all!
I think now that the namespace issues in libosmocore have been resolved,
we seriously have to think of maintaining a stable API and ABI. This
allows us to have truly independent library and application releases,
and the dynamic linker library versioning support should ensure
compatibility.
Would it be worth if we make opaque declaration of some structures
opaque? e.g. struct osmo_timer_list in the header file, and the real
declaration in
Encapsulation is good to avoid breaking backward compatibility. Not sure
if we expect that this structure would ever change.
Let me know if I'm being too conservative :-).
So please think twice about any modifying libosmocore.
It is safe to
add new functions, but we cannot change the prototypes (number of
arguments) for existing functions.
As soon as new functions are introduced, we should increment the library
interface number.
For more information, see
http://www.gnu.org/software/libtool/manual/libtool.html#Versioning
especially the rules in Chapter 7.3:
# If the library source code has changed at all since the last update,
then increment revision (‘c:r:a’ becomes ‘c:r+1:a’).
# If any interfaces have been added, removed, or changed since the last
update, increment current, and set revision to 0.
# If any interfaces have been added since the last public release, then
increment age.
# If any interfaces have been removed or changed since the last public
release, then set age to 0.
I think that we should also use a map file [1] and the EXPORT_SYMBOL
declaration [2].
I can make a patch to support this.
These references point to libmnl as one example of mine:
[1]
http://git.netfilter.org/cgi-bin/gitweb.cgi?p=libmnl.git;a=blob;f=src/libmn…
[2]
http://git.netfilter.org/cgi-bin/gitweb.cgi?p=libmnl.git;a=blob;f=src/inter…