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

[Daniel Pocock]

On 01/08/13 17:03, Byron Campen wrote:
>
>
> On Thu, Aug 1, 2013 at 12:57 AM, Daniel Pocock <daniel at pocock.com.au
> <mailto:daniel at pocock.com.au>> 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)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20130802/6ee861a9/attachment.htm>