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

Byron Campen docfaraday at gmail.com
Wed Jul 31 22:33:52 CDT 2013


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.

Best regards,
Byron Campen

On Wed, Jul 31, 2013 at 10:14 AM, Daniel Pocock <daniel at pocock.com.au>wrote:

>
>
> Catalin and I have discovered issues trying to use the reSIProcate
> headers to compile a standalone project
>
> Basically, we had to duplicate many of the definitions into the
> dependent project, as demonstrated in this commit:
>
>
> https://github.com/catalinusurelu/reConServer/commit/8644e5d581c361fa5eee5f2fbf405cb3cc76f7fa
>
> It is OK hardcoding these things for a known platform (Catalin is
> testing the Debian packages, so he knows what flags I used for the
> build) but not convenient for widespread usage.
>
> Without having all the right flags, we observed that the compile would
> succeed, process would run, but at some point later we would get a
> segfault (for reConServer, the segfault occurs when the first call comes
> in) so this is likely to be frustrating for other people trying to build
> things that depend on reSIProcate.
>
> I can think of a few ways to proceed:
>
> best solution: can we make the public API completely static with respect
> to compile flags?  E.g. not using #ifdef USE_IPV6 or #ifdef USE_SSL in
> *.hxx?
>
> config.h: we can't distribute a full config.h from autotools - nor
> should we, it will clash with config.h in dependent projects, we already
> experienced that problem with srtp/config.h.  We could create something
> derived from config.h though and distribute that.
>
> config binary:  e.g. some script, bin/xxx-config that can be invoked
> like this:
>
> RESIP_CPPFLAGS=`/usr/bin/resip-config --cppflags`
>
> I raised this on the autoconf mailing list too
> http://lists.gnu.org/archive/html/autoconf/2013-07/msg00055.html
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel at resiprocate.org
> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20130731/ccc8834d/attachment.htm>


More information about the resiprocate-devel mailing list