./configure options of note

These are options passed to the

./configure

command after calling

autoreconf

but before calling

make build

...

Build tips

Diagnosing errors building rpms

First tip is to make sure all the files needed to build are in the tarball. Often, this is the problem. If files are not missing, and you want to re-run the specific build commands that failed you must first enter the build environment using a chroot shell. Run this command altering the -r centos-5-x86_64 parameter to your desired distribution id.

mock --configdir=mak/mock -r centos-5-x86_64 --shell
mock-chroot> cd /builddir/build/BUILD/*/
make

Then you can look around and try to find the issue with make. To exit, simple type "exit".

Separating binaries from source

This has 3 advantages: easy to start over, easy to see source changes, allows for multiple sets of build settings. To direct output to different directory, simply run ./configure script from another directory. This is handy when you want to mass delete all build output when you want to start over. Its also handy for creating multiple build with differnent configuration

...

.

 mkdir my-build-output

...

 cd my-build-output

...

 ../configure 

• To see all configuration options, run the following command, it can be quite overwhelming! and unfort. quite redundant

  Panel
  --help=recursive

• If you're not going to read the C++ documentation, this will speed things up

  Panel
  --disable-doxygen

...

Faster Builds is ccache

Used ccache when same rebuilding source tree often. For CentOS or Redhat install ccache rpm from dag wiers repository at: http://dag.wieers.com/packages/ccache/. For Fedora use sudo yum install ccache. To enable ccache, add the following settings to your environment before running any make targets

 export CC="/usr/bin/ccache gcc"
 export CXX="/usr/bin/ccache g++"

Rebuilding after editing Makefile.am

If you edit a Makefile.am, you may not have to re-run autoreconf or configure. Built into the Makefile is the ability to regenerate itself, simply run your target as you normally would. If you make a change however that is of improper syntax, you will have to rerun autoreconf and configure

Rebuilding after editing configure.ac

If you want to rerun ./configure command with the same arguments, you can just run ./config.status --recheck && ./config.status

Custom location for Openfire

If you have installed the openfire

...

in a non standard location (i.e. other than /opt/openfire)

...

./configure ... OPENFIRE_HOME=path-to-openfire

• Handy when you want server to run as the user building the source so you can debug easier and gdb/ddd will find source automatically

  Panel
  SIPXPBXUSER=`whoami`

Installing multiple versions of sipxecs

If you plan to install multiple builds, you can direct the installation to a directory other than

/usr/local/sipx

by adding this switch. You can use any directory name

...

./configure ... --prefix=/opt/sipx

• If you want CDR support, add the following option. (Requires ruby and development tools like gem and rake)

  Panel
  --enable-cdr

Faster configure phase using configure cache

To speed up

configure

step, this can decrease the time by 40%. You can use any file name

...

./configure ... --cache-file=/tmp/ac-cache-file

• If you change Makefile.in in the top directory you can just run this command to regenerate Makefile

  Panel
  --no-recursion

• What is also good for people doing builds in the same directory often, is to use ccache. For example for centos or redhat you would install the ccache rpm from dag wiers repository at: http://dag.wieers.com/packages/ccache/, on FC try

  Panel
  sudo yum install ccache and than add the following settings to your environment: export CC="/usr/bin/ccache gcc" export CXX="/usr/bin/ccache g++"

autotools tips of note

• After running

  Code Block
  autoreconf -if

  once, subsequent times you can just run

  Code Block
  autoreconf

  to speed things up a bit

  Panel
  autoreconf -if

  subsequently if you make a change to any configure.ac or autoconf macro

  Panel
  autoreconf

• To re-run a

  Code Block
  configure

  script from the build target directory. (Thanks to Damian K. for finding this one.)

  Panel
  ./config.status --recheck && ./config.status

make options of note

...

...

...

...

Quieter builds

To supress some (but not nearly all) extraneous output

...

make -s

...

...

...

autoreconf

...

configure

...

autoreconf

...

configure

Troubleshooting

...

Help on all available make targets

Running make with no targets will return useful list of targets. This is useful if you're unfamiliar with building sipXecs or if you often forget a target name or exact syntax.

Troubleshooting

1. Failed named tests If your build reports errors on named related tests, you do not have the nameserver running or your nameserver is mis-configured. In this case edit out the offending tests.
2. Failed timer related tests If you are running on older harware some of the timer related tests may report errors. Ignore these errors.Keep your build environment clean. It is best to not have the sipx*devel tools installed on the machine ( or virtual machine file system ) where you want to build your source code. You can pick up stale libraries and includes that can drive you up the wall. If you are building RPMS, note that RPMS are also installed when you build them. You can list all the installed RPMS using rpm -q -all.