< Previous by Date Date Index Next by Date >
< Previous in Thread Thread Index Next in Thread >

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




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.

Best regards,
Byron Campen