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

[Byron Campen]

On Thu, Aug 1, 2013 at 12:57 AM, Daniel Pocock <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.

Best regards,
Byron Campen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20130801/d8d7b31b/attachment.htm>