Re: [reSIProcate] public API, config.h and CPPflags issues
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@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx
https://list.resiprocate.org/mailman/listinfo/resiprocate-devel