Re: [reSIProcate] public API, config.h and CPPflags issues

[Daniel Pocock <daniel@xxxxxxxxxxxxx>]

On 01/08/13 17:03, Byron Campen wrote:

On Thu, Aug 1, 2013 at 12:57 AM, Daniel Pocock <daniel@xxxxxxxxxxxxx> wrote:

On 01/08/13 06:06, Byron Campen wrote:

Ok, looks like our culprits this time are HAVE_EPOLL (which turns on RESIP_POLL_IMPL_EPOLL, which completely changes the API and ABI in rutil/Poll), and USE_SSL (which appears in many places in reTurn, recon, and reflow.) USE_IPV6, RESIP_ARCH_*, RESIP_OSTYPE_*, USE_CARES, and HAVE_sockaddr_in_len seem ok wrt the resip codebase. I'll start looking into it.

Ok, I just took everything I could see and copied it into the dependent project just to test my hunch that this was the issue.  Thanks for narrowing this down to the real culprits.

Personally, I think that we should remove this #ifdef crud from our header files wherever possible. A while back I purged most of this, but it seems more has crept back in.

I could put something in the build system like this:

  find $DESTDIR -name '*.hxx' -exec grep -H ^.ifdef

and fail the build if it spots anything.  $DESTDIR is the output directory for the API to be distributed.  travis-ci would run this test after every commit.

That'll trip over the standard include guard stuff. I've been itching to look into whether this could be of any use:

http://ispras.linuxbase.org/index.php/ABI_compliance_checker

I do not know whether this is sophisticated enough to fiddle the preprocessor defs automatically.  

I've tried looking for a tool that just scans a header file and looks for stuff like ifdef around members, virtual functions, and other things that will cause the memory layout of the class to change. I have not found such a thing, sadly. Might be a fun little project to try to whip something like this up.

Ok, for the 1.8.12 release:

- we have the possibility of using the cstdint branch (using standard size integer types), this doesn't appear 100% ABI compatible and actually required changes to method prototypes in the class Data - however, it is generally a good change for stability on multiple platforms

- we have the reality that previous 1.8.x releases are not 100% ABI consistent with each other (or even comparing the same 1.8.x release built by two different people, they may not be 100% ABI compatible)

Since 1.8.0, when we started using autotools and particularly libtool, I've been encoding SONAMEs in all libraries using "-release".  I have not used "-version-info" for the moment because it is painful to maintain if the API/ABI changes frequently and for a project like reSIProcate, users probably need to take some care when moving to a new version.

There are a few ways forward:

a) we can just leave the 1.8.x branch as it is for now and focus on releasing these fixes in 1.9.x some time in the next 2-3 months (and we should consider adding -version-info for 1.9.x and beyond)

b) we can put the fixes into the 1.8 branch and use use both "-version-info" and "-release" together.  For 1.8.12, we would set "-version-info 1:0:0" and artifacts would have names like librutil-1.8.so.1 - this means that users would be forced to rebuild dependent projects and would not accidentally run some combination that is not ABI compatible.  Example:

1.8.0 - 1.8.11 artifacts have names like librutil-1.8.so
1.8.12 and beyond have names like librutil-1.8.so.1

c) we can create a new branch for the 1.9 series as a copy of the current 1.8 branch and then just add in the ABI-related fixes.  1.9 will then have much the same functionality as 1.8 but a more predictable ABI.  More dramatic changes like the WebRTC support would come in 1.8.10 or maybe a 2.0.0 release.

We could also mix-and-match, e.g. if we go with (a), we can optionally make a decision to start adding "-version-info" from 1.9 onwards

Also, I'm assuming that in a given release, all libraries (librutil, libresip, libdum, etc) will have the same "-version-info".  I've heard of other projects that release multiple libs from a single source tree and track each version spec independently, but that is regarded as a more painful thing to maintain and produce packages.

My preference is for (a) or (b)