Configuration Options

From reSIProcate
Revision as of 18:38, 26 November 2008 by Adam (talk | contribs)
Jump to navigation Jump to search

Because the resiprocate project does not use GNU autotools, it has its own configuration system that can be used to select various options within the project, as well as what parts of the project are built. By default, if you just type 'make', the configuration script is invoked by the makesystem, and some (mostly) sane defaults are chosen for you.

However, if you want to take advantage of the advanced, new, and/or experimental features available within resiprocate, you really want to take advantage of the configuration system. Currently, you have three options:

  • ./configure - Invoke the configuration system in a text questionnaire mode. This can be tedious, but should work under all terminal environments.
  • ./configure -m - Invoke the configuration system in a (somewhat experimental) text-based menu mode. This is much easier to use, but requires a vt100-compatible that is tall enough to accommodate all the configuration options.
  • ./configure -y - Invoke the configuration system in a non-interactive mode. Configuration options will be set to defaults if they don't yet exist, and then any configuration-changing commandline switches will be applied. If the system is already configured, no options will be changed except as specified by commandline switches.

Note that the defaults chosen for some options vary from platform to platform, and even according to what is installed on the system when configuration is invoked.

The various options currently available in the configuration system are:

       Which toolchain do you want to use?
       Valid values are: [gnu, intel, sunpro, msgnu, gnu-cross]
       What is the name your toolchain uses for the cross platform?
       What is the prefix for the cross-compiler binaries?
       Where is your cross compiler installed?
       What compile profile will you use?
       Valid values are: [debug, nodebug, opt, gopt, prof, small]
       Should the resip libraries be built shared?
       Will you be using distcc?
       Will you be using ccache?
       Build the Repro proxy server?
       Which database should be used with Repro?
       Valid values are: [berkeley-db4]
       Where is db_cxx.h?
       Build the RADIUS authentication module? (requires radiusclient-ng)
       Build the TFM test framework?
       Build the reCon Conversation Manager? (requires dtls-srtp patched OpenSSL)
       Build the reTurn client?
       Build the reTurn server?
       Where is boost/config.hpp?
       Are the sipX libraries and headers installed?
       Where is the common root of the sipX libraries?
       Where are the sipX libraries installed?
       Where are the sipX header files installed?
       Include SIP over TLS, SMIME or Identity header support? (Requires OpenSSL)
       Do you want to include SIP over DTLS support? (Requires OpenSSL 0.9.8+)
       Where is OpenSSL? (leave blank to use installed copy)
       Should DUM use curl to retreive identity information?
       Use the Google malloc() implementation?
       Use Google cpuperf?
       Compile in IPv6 support?
       Use popt to read commandline options?
       Where is popt.h?
       Where is libpopt?
       Compile with no floating point functions?
       Force stack to fully parse every message it receives?
       Where should the libraries be installed?
       Which DNS resolution library do you want to use?
       Valid values are: [resip-ares, c-ares]

Support for c-ares remains experimental. Note that using c-ares with resiprocate requires a bleeding-edge copy of c-ares at the moment. See the c-ares project page for information about obtaining a copy of c-ares from their cvs repository.

       Where should ares be installed?
       If using c-ares, the directory containing its headers.
       If using c-ares, the directory containing its libraries.